[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mod_auth_saml not setting the auth user



Sorry, I missed this one. Been busy.

Karthik Sudarshan <ksudarshan@xxxxxxxxxx> said:
> Hi Sampo,
>     Thanks a lot for the reply. I think it may have to do with the Apache
> version. I tried the same on Apache 2.2 and it works fine even with
> REDIR_TO_CONTENT. So you may be right, in that the newer version of Apache
> might require something other than REMOTE_USER for the valid-user
> requirement to pass. But since our environments run on 2.2 we are fine.
> 
> The version of zxid I used is the latest : 1.16. Platform Ubuntu Linux v12
> (on a VirtualBox).
> 
> I have now been able to access the authenticated content.
> 
> I have a few more questions (mostly due to the lack of my understanding I
> guess) :
> 1. I have a Java web app running on Tomcat, and Apache is fronting it using
> mod_jk and doing the SAML choreography to protect the web app using the
> mod_auth_saml module. After the SAML authentication is completed, it
> properly passes the control to the protected web app on Tomcat. However, in
> the HTTP headers I see that only the ZXIDSES cookie is accessible. Is there
> an easy way to access the original SAML response content (like the nameId)
> in the HTTP request, apart from calling the ZXID api (JNI api in this case)?

I am not horribly familiar with mod_jk, but Apache httpd has this notion
of the execution environment. If you run a CGI, you see them as environment
variables. I also know they get correctly passed to php. By extension,
I would expect mod_jk to pass them to tha app server as well.

If this is not working, then it might be a bug.

However, if you get the session ID, you can probably recover the
attributes even if the execution environment is not correctly passed.

Basically you would first call zxjni.fetch_ses() with the session ID
string and then zxidjni.ses_to_qs() (or to ldif or to json) and
parse the output.

> 2. If there are saml:attributes in the assertion returned by the IDP, will
> these attributes be set as the HTTP headers for the requests to the
> protected app?

They should be. mod_auth_saml passes them to Apache execution environment.
My understanding is that they pass to mod_jk. I know they pass to cgi and php.

> 3. If the IDP does not advertise the fact that there are saml:attributes
> available in the assertion in its metadata,

ZXID does not depend on the IdP advertising attributes in metadata. It
will pickup whatever attributes it can find, irrespective of the
metadata.

Also, zxididp, generates attributes without advertising in metadata
that it will do so.

> and send the attributes in the
> data, the session does not get created on the SP (no ZXIDSES cookie is
> created), and the page is redirected to the IDPSEL page with the url :
> /protected/saml?o=P. Is this the expected behavior? However, if the
> saml:attributes are not sent in the assertion, then things work properly.

That sounds weird. Upon receiving valid assertion, the cookie should
be set irrespective of the presence of attributes or not. Please debug
further and try to isolate what is going on.

Cheers,
--Sampo

> 
> Regards,
> Karthik
> 
> 
> 
> 
> On Sat, Nov 16, 2013 at 7:09 PM, <sampo@xxxxxxxx> wrote:
> 
> > Please supply version data for zxid and platform.
> >
> > Karthik Sudarshan <ksudarshan@xxxxxxxxxx> said:
> > > I have setup the Apache 2.4.6 web server on my Ubuntu install (built the
> > > Apache server from source, since the mod_auth_saml requires access to the
> > > various .h files in the include directory, which is not available in the
> > > direct package downloaded by Ubuntu).
> >
> > While compiling apache yourself is certainly OK, it usually is not
> > necessary as most Linux distributions offer packages that have the
> > necessary headers, e.g.
> >
> > sudo apt-get install libapr1-dev
> > sudo apt-get install apache2-dev
> >
> > > On this I was able to compile the mod_auth_saml and generate the
> > > mod_auth_saml.so file.
> > >
> > > I was also able to configure my IDP using the zxcot tool (zxcot -g
> > > metadata-url).
> > >
> > > I configured the /protected location.
> > >
> > > Then I accessed the /protected/test.html file, and I was redirected to
> > the
> > > IDP selection page. Here I could see the IDP I had setup using the zxcot
> > > tool, and I selected the same for login.
> > >
> > > I was promptly redirected to the IDP login page, and after successfully
> > > logging in there, I was redirected to the original /protected/test.html
> > > file, and here I got an "Internal Server Error".
> > >
> > > This was because the mod_authz_core module cannot recognize that there is
> > > an authenticated user available, and it prints the message :
> > >
> > > "AH00027 No authentication done but request not allowed without
> > > authentication for /protected/test.html. Authentication not configured?
> > > referrer ...."
> > >
> > > I checked on the browser for the cookies and the cookies were set for the
> > > ip address for the IDP and for the SP. Also ZXIDSES cookie was created.
> > >
> > > Further, in the log I could also see the message from zxid PDP as
> > > "PERMIT by local PDP val(<username>) nid(<username>)"
> > >
> > > If you can shed any light as to what I'm missing it will be extremely
> > > helpful.
> >
> > 1. Although the REDIR_TO_CONTENT option is fully supported,
> >    try without it and report what happens.
> >
> > 2. The destination of REDIR_TO_CONTENT is carried in SAML
> >    protocol using RelayState field, which may appear as rs
> >    in ZXID logs. Given the error messages you received,
> >    it seems probable that the REDIR_TO_CONTENT and RelayState
> >    worked.
> >
> > 3. Upon successful SSO, ZXID sets REMOTE_USER in apache
> >    context (from where it propagates to be environment
> >    variable visible to CGIs, etc.). Please try to scan
> >    the logs for whether this variable was set.
> >
> >    In my best understanding this is all that needs to be
> >    done for the "Require valid-user"
> >    condition to be satisfied, but perhaps I am missing something?
> >    My own testing tends to be against Apache 2.2 so this could
> >    be a factor, too. I still want to support 2.4, however, so
> >    if there is something 2.4 requires, I want to add it.
> >
> > 4. Doublecheck that you do not have any .htaccess file or
> >    other authentication related modules involved. Sometimes
> >    these are confusingly called authorization modules even if
> >    they only implement checking authentication and then
> >    have default policy that every authenticated user is an
> >    authorized user.
> >
> > Cheers,
> > --Sampo
> >
> > > Regards,
> > > Karthik
> > >
> > > PS :
> > >
> > > the conf settings is as follows:
> > >
> > > LoadModule auth_saml_module /usr/local/apache2/modules/mod_auth_saml.so
> > >
> > > <Location /protected>
> > >     Require valid-user
> > >     AuthType "saml"
> > >     ZXIDConf "URL=http://<ipaddress>/protected/saml"
> > >     ZXIDConf "REDIR_TO_CONTENT=1"
> > > </Location>
> > >
> > > --
> >
> >
> 
> -- 
> 
> ------------------------------
> <http://www.xtivia.com>  <http://www.virtual-dba.com/> <http://www.virtual-dba.com/><http://www.virtual-asa.com/>
>   <http://www.facebook.com/Xtivia>  <http://twitter.com/#!/xtivia> <http://www.linkedin.com/company/xtivia>
>   <http://blogs.xtivia.com>  <http://www.xtivia.com/resources/webinars>
> *Xtivia Virtual-Services (DBA/ASA) Customer Support: (800) 205-7537*
> ------------------------------
> This e-mail may contain confidential or privileged information. If you 
> believe you have received this e-mail in error, please notify the sender by 
> reply e-mail and then delete this e-mail immediately.