<span id="mailbox-conversation"><div>So here’s the sequence of requests when it loops and the <location> block is uncommented:</location></div>
<div><br></div>
<div>GET / - 302 redirects to the IdP.</div>
<div><div><requests to the IdP></div></div>
<div>POST /Shibboleth.sso/SAML2/POST - 302 redirects to /a-url-in-my-app which means that it’s actually getting past the authentication I think since it’s forwarding to my app.</div>
<div>GET /a-url-in-my-app - 302 redirects to the IdP with a new auth request.</div>
<div><requests to the IdP></div>
<div><br></div>
<div>The interesting thing here is the fact that even when it loops it’s actually getting to my app for one request. I know this because my app is the one doing the redirect from / to /a-url-in-my-app.</div>
<div><br></div>
<div>The issue appears to be that the POST request doesn’t set a _shibsession_<hash> cookie in the response. So when the browser next requests my /a-url-in-my-app, it has to re-request authentication from the IdP.</div>
<div><br></div>
<div>When I comment out the <Location> block, the POST request responds with the same 302 redirect but also a _shibsession_<hash> cookie so that subsequent GET /a-url-in-my-app is allowed because it passes the session cookie.</div>
<div><br></div>
<div>Does this still point to the POST request not being properly handled or possibly something else? I would think that if it were not handled by Shibboleth it wouldn’t try to forward me to my app because I wouldn’t be authenticated.</div>
<div><br></div>
<div>Thanks again for the help on this. It feels like something subtler than a library mismatch but perhaps not.</div></span><div class="mailbox_signature"><br></div>
<br><br><div class="gmail_quote"><p>On Tue, Oct 14, 2014 at 11:07 AM, Bradley Wagner <span dir="ltr"><<a href="mailto:bradley.wagner@hannonhill.com" target="_blank">bradley.wagner@hannonhill.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span id="mailbox-conversation"><div>
<div id="mb-reply">Thanks Scott. </div>
<div id="mb-reply"><br></div>
</div>
<div>> That means the URL base in question was not treated as the effective handlerURL for the request. The SP will never impose itself in front of the handlers unless it doesn’t know they’re handlers.</div>
<div><br></div>
<div>I’m somewhat new to Shibboleth. Where would this be configured? In Apache or in Shibboleth? I tried setting handlerURL in my <Sessions> in shibboleth2.xml which didn’t address this.</div>
<div><br></div>
<div>
<div id="mb-reply">> It wasn’t my idea to include that material. Other people asked me to. It has never been necessary for me but apparently it can cause issues whether it’s there or not. </div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Got it. Thanks for clarifying.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">> But I can say that it cannot cause a redirect to the IdP, because only the SP itself can do that and it won’t decide that based on Satisfy or Allow commands. The reason those were supposedly needed is to prevent Apache itself from getting in the way in some cases, but that would cause local blocking of the requests, not redirects or looping.</div>
<div id="mb-reply">
<div id="mb-reply"><br></div>
<div id="mb-reply">Got it. That’s good to know. All I know is that the only difference in my config between it working and properly handling the POST requests from the IdP and extracting the auth information and it not working and redirecting to the IdP is that block.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">
<div id="mb-reply">> If I were to try and debug it, I’d probably be focusing on the more usual cause of handler issues and debug the RequestMapping process in native.log and see what it thinks the requests to those handlers looks like.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Yes, I had tried this.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">I enabled a bunch of DEBUG logging in shibd.logger including log4j.category.Shibboleth.RequestMapper but only ever saw the following in the log:</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">
<div>2014-10-14 10:05:18 DEBUG Shibboleth.Listener [1]: dispatching message (default/Login::run::SAML2SI)</div>
<div>2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: validating input</div>
<div>2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: marshalling, deflating, base64-encoding the message</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshal samlp:AuthnRequest</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshalling saml:Issuer</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshalling samlp:NameIDPolicy</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject</div>
<div>2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject (document is bound)</div>
<div>2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: marshalled message:</div>
<div><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://<REDACTED>/Shibboleth.sso/SAML2/POST" Destination=“<REDACTED>" ID=“_<REDACTED>" IssueInstant="2014-10-14T15:05:18Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://<REDACTED>/shibboleth</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest></div>
</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">So the native.logger instead? Any particular category? log4j.category.Shibboleth.RequestMapper? What’s the difference between the two loggers? Should the same categories show different stuff in both loggers?</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Thanks again. I’m hoping to sort this out so this thread cans serve as record for future me should I ever run into this again :-).</div>
</div>
</div>
</div></span><div class="mailbox_signature"><br></div>
<br><br><div class="gmail_quote">
<p>On Tue, Oct 14, 2014 at 10:13 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>></span> wrote:<br></p>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>On 10/14/14, 9:57 AM, "Bradley Wagner" <bradley.wagner@hannonhill.com>
<br>wrote:
<br>>
<br>>I was running into an issue where I ultimately determined that the
<br>>Shibboleth URLs: /Shibboleth.sso/* were not being properly handled by
<br>>Apache. Every request, including the POST request from the IdP, were
<br>>being handled as new requests that required authentication instead of a
<br>>request containing auth information that should have been handled
<br><br>That means the URL base in question was not treated as the effective
<br>handlerURL for the request. The SP will never impose itself in front of
<br>the handlers unless it doesn't know they're handlers.
<br><br>>The fix, ironically, was to comment out this section of the mod_shib.conf
<br>>file that shipped with Shibboleth even though the comment says the point
<br>>of that block is ensure the handle will be accessible.
<br><br>It wasn't my idea to include that material. Other people asked me to. It
<br>has never been necessary for me but apparently it can cause issues whether
<br>it's there or not. But I can say that it cannot cause a redirect to the
<br>IdP, because only the SP itself can do that and it won't decide that based
<br>on Satisfy or Allow commands. The reason those were supposedly needed is
<br>to prevent Apache itself from getting in the way in some cases, but that
<br>would cause local blocking of the requests, not redirects or looping.
<br><br>>but I could never get the handler to be invoked for the Shibboleth.sso
<br>>URLs. The fix ultimately was to comment out the block in mod_shib.conf at
<br>>which point it magically started working. I didn't even need a block to
<br>>explicitly "SetHandler shib" once that initial block was commented out.
<br><br>SetHandler is only required in Apache 1.3, it's never been needed since.
<br>Apache 2+ has always been broken in that it runs *every* handler
<br>registered until something responds, and it can't be controlled by MIME
<br>type of URL (this is despite what the docs say). So that's nothing unusual.
<br><br>I have no idea about the rest, it isn't consistent with anything I
<br>understand about Apache.
<br><br>If I were to try and debug it, I'd probably be focusing on the more usual
<br>cause of handler issues and debug the RequestMapping process in native.log
<br>and see what it thinks the requests to those handlers looks like.
<br><br>-- Scott
<br><br>--
<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
<br></p></blockquote>
</div>
<br></blockquote></div><br>