no default shibboleth headers after successful authentication

[Cane Cubtow]

Hmmm i have been looking at the two logs i think are most relevant
(shibd.log and native.log) and cant seem to see an issue with anything...
from the native.log i see the saml assertion getting posted, then the
redirect to the app page that is expecting the headers, but they are not
there so the app redirects (302) to the unauthorized page... the repid is
correctly populating the remote_user env variable...


from /var/log/httpd/native.log
10.10.42.211 - - [24/Apr/2015:15:09:32 -0400] "POST
/Shibboleth.sso/SAML2/POST HTTP/1.1" 302 259
10.10.42.211 - 50001 [24/Apr/2015:15:09:32 -0400] "GET
/app1/singlesignon/SsoShibbolethService HTTP/1.1" 302 -
10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET
/app1/app/unauthorized.jsp HTTP/1.1" 200 3506
10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET
/app1/app/favicon.ico HTTP/1.1" 302 -
10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/index.html
HTTP/1.1" 200 4809
10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET
/app1/app/favicon.ico HTTP/1.1" 302 -
10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/index.html
HTTP/1.1" 200 4809


from /var/log/shibboleth/shibd.log
2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: SSO profile processing
completed successfully
2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: extracting pushed
attributes...
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeExtractor.XML [3]: unable to
extract attributes, unknown XML object type: samlp:Response
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeDecoder.String [3]: decoding
SimpleAttribute (repid) from SAML 2 NameID with Format
(urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName)
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeExtractor.XML [3]: unable to
extract attributes, unknown XML object type: saml:AuthnStatement
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeFilter [3]: filtering 1
attribute(s) from (http://<idp_url>:7499/fed/idp)
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeFilter [3]: applying
filtering rule(s) for attribute (repid) from (http://<idp_url>:7499/fed/idp)
2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: resolving attributes...
2015-04-24 15:09:32 DEBUG Shibboleth.AttributeResolver.Query [3]:
attempting SAML 2.0 attribute query
2015-04-24 15:09:32 WARN Shibboleth.AttributeResolver.Query [3]: no SAML 2
AttributeAuthority role found in metadata
2015-04-24 15:09:32 DEBUG Shibboleth.SessionCache [3]: creating new session
2015-04-24 15:09:32 DEBUG Shibboleth.SessionCache [3]: storing new
session...
2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record
(session) in context (_f0c0723e7934e84bfd453b6a9168c6b2) with expiration
(1429906172)
2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record
(50001) in context (NameID) with expiration (1429904070)
2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record
(id--3YKSuX-F1sd6dqmfXyqYqHllI4-) in context
(_f0c0723e7934e84bfd453b6a9168c6b2) with expiration (1429906172)
2015-04-24 15:09:32 INFO Shibboleth.SessionCache [3]: new session created:
ID (_f0c0723e7934e84bfd453b6a9168c6b2) IdP (http://<idp_url>:7499/fed/idp)
Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (10.10.42.211)
2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: ACS returning via
redirect to: http://<vhost_fqdn>/app1/singlesignon/SsoShibbolethService
2015-04-24 15:09:32 DEBUG Shibboleth.Listener [3]: dispatching message
(default::getHeaders::Application)
2015-04-24 15:09:32 DEBUG Shibboleth.Listener [3]: dispatching message
(find::StorageService::SessionCache)
2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: updated expiration
of valid records in context (_f0c0723e7934e84bfd453b6a9168c6b2) to
(1429906172)
2015-04-24 15:09:33 DEBUG Shibboleth.Listener [3]: dispatching message
(touch::StorageService::SessionCache)





On Fri, Apr 24, 2015 at 2:31 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 4/24/15, 2:25 PM, "Cane Cubtow" <cane at vander.ca> wrote:
>
> >Thanks for the reply Scott... I guess I am trying to understand the
> relationship between the Apache location and the proxying to the app on
> jboss via JkMount... here is the mod_jk settings... its basically proxying
> anything that matches /app1/*
>
> The Apache settings are the only part relevant to the SP. Whether that
> lines up correctly with whatever you mounted is of course a different
> question outside of my view.
>
> >JkMount /app1/* loadbalancer
> >
> >So is the fact that the apache locationmatch /app1/singlesignon/* and the
> JkMount /app1/*  both match causing the issue?
>
> No.
>
> You have logging, you need to use it. The native.log, properly bumped up
> to DEBUG, will include a lot of details about the URLs the SP is seeing and
> what they look like. Most likely that will point to a bug, such as if you
> see no sign of it processing requests that you think it should be seeing.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150424/5758317c/attachment.html>