<div dir="ltr"><div>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... </div><div><br></div><br><div>from /var/log/httpd/native.log</div><div><div><font face="monospace, monospace">10.10.42.211 - - [24/Apr/2015:15:09:32 -0400] "POST /Shibboleth.sso/SAML2/POST HTTP/1.1" 302 259</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:32 -0400] "GET /app1/singlesignon/SsoShibbolethService HTTP/1.1" 302 -</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/unauthorized.jsp HTTP/1.1" 200 3506</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/favicon.ico HTTP/1.1" 302 -</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/index.html HTTP/1.1" 200 4809</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/favicon.ico HTTP/1.1" 302 -</font></div><div><font face="monospace, monospace">10.10.42.211 - 50001 [24/Apr/2015:15:09:33 -0400] "GET /app1/app/index.html HTTP/1.1" 200 4809</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"><br></font></div><div>from /var/log/shibboleth/shibd.log<font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: SSO profile processing completed successfully</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: extracting pushed attributes...</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.AttributeExtractor.XML [3]: unable to extract attributes, unknown XML object type: samlp:Response</font></div><div><font face="monospace, monospace">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)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.AttributeExtractor.XML [3]: unable to extract attributes, unknown XML object type: saml:AuthnStatement</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.AttributeFilter [3]: filtering 1 attribute(s) from (http://<idp_url>:7499/fed/idp)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.AttributeFilter [3]: applying filtering rule(s) for attribute (repid) from (http://<idp_url>:7499/fed/idp)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: resolving attributes...</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.AttributeResolver.Query [3]: attempting SAML 2.0 attribute query</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 WARN Shibboleth.AttributeResolver.Query [3]: no SAML 2 AttributeAuthority role found in metadata</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SessionCache [3]: creating new session</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SessionCache [3]: storing new session...</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record (session) in context (_f0c0723e7934e84bfd453b6a9168c6b2) with expiration (1429906172)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record (50001) in context (NameID) with expiration (1429904070)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: inserted record (id--3YKSuX-F1sd6dqmfXyqYqHllI4-) in context (_f0c0723e7934e84bfd453b6a9168c6b2) with expiration (1429906172)</font></div><div><font face="monospace, monospace">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)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.SSO.SAML2 [3]: ACS returning via redirect to: http://<vhost_fqdn>/app1/singlesignon/SsoShibbolethService</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.Listener [3]: dispatching message (default::getHeaders::Application)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG Shibboleth.Listener [3]: dispatching message (find::StorageService::SessionCache)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:32 DEBUG XMLTooling.StorageService [3]: updated expiration of valid records in context (_f0c0723e7934e84bfd453b6a9168c6b2) to (1429906172)</font></div><div><font face="monospace, monospace">2015-04-24 15:09:33 DEBUG Shibboleth.Listener [3]: dispatching message (touch::StorageService::SessionCache)</font></div></div><div><font face="monospace, monospace"><br></font></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 24, 2015 at 2:31 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4/24/15, 2:25 PM, "Cane Cubtow" <<a href="mailto:cane@vander.ca">cane@vander.ca</a>> wrote:<br>
<br>
>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/*<br>
<br>
</span>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.<br>
<br>
>JkMount /app1/* loadbalancer<br>
<span class="">><br>
>So is the fact that the apache locationmatch /app1/singlesignon/* and the JkMount /app1/* both match causing the issue?<br>
<br>
</span>No.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>