<span id="mailbox-conversation"><div>Thanks again Scott. I appreciate all of the prompt and thorough responses.</div>
<div><br></div>
<div>
<div>> Yes, exactly. And it’s not doing that, it’s going *directly* to /login.act, not to / first and then redirecting. You’d see that redirect in the log. One possibility I guess is a cached redirect, but that’s a really bad thing in and of itself.</div>
<div><br></div>
<div id="mb-reply">Ah, I see what you’re saying. Yes, it does appear to be going directly to /login.act right after the "POST /Shibboleth.sso/SAML2/POST”. I assumed that was Apache proxying to my app and then my app responding with the redirect /login.act. But you’re right that it looks different in the case where it works. Specifically, it requests / before /login.act:</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">
<div>66.194.102.6 - - [14/Oct/2014:11:26:03 -0500] "GET / HTTP/1.1" 302 929 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36"</div>
<div>66.194.102.6 - - [14/Oct/2014:11:26:05 -0500] "POST /Shibboleth.sso/SAML2/POST HTTP/1.1" 302 326 "https://<REDACTED>/idp/profile/SAML2/Redirect/SSO" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36"</div>
<div>66.194.102.6 - <REDACTED>@<REDACTED> [14/Oct/2014:11:26:05 -0500] "GET / HTTP/1.1" 302 - "https://<REDACTED>/idp/profile/SAML2/Redirect/SSO" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36"</div>
<div id="mb-reply">66.194.102.6 - <REDACTED>@<REDACTED> [14/Oct/2014:11:26:05 -0500] "GET /login.act HTTP/1.1" 302 - "https://<REDACTED>/idp/profile/SAML2/Redirect/SSO" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36”</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">And I see the principal (REDACTED above) in both requests.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">> The problem, simply put, is that I have no idea how Satisfy/Allow and so forth work (I’ve never read a coherent explanation of those commands and they’re even more confusing in 2.4 now) but they probably are causing the result of the POST to turn into something totally unexpected as a consequence of Apache error configuration somewhere. Clearly they are actually blocking access to it.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Yep, agreed. I too have never understood how to use them effectively.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">> If they don’t work, I would just get rid of them. That simple, really.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Sounds good. I think it was the comment that threw me off since it indicated that it should be included to ensure the handlers are accessible.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Would it be worth noting that these directives may or may not be necessary but should probably be left off by default?</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">I’d be happy to make a commit to that effect.</div>
<div id="mb-reply"><br></div>
<div id="mb-reply">Thanks!</div>
</div>
</div></span><div class="mailbox_signature"><br></div>
<br><br><div class="gmail_quote"><p>On Tue, Oct 14, 2014 at 12:59 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">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, 12:42 PM, "Bradley Wagner" <bradley.wagner@hannonhill.com>
<br>wrote:
<br>>
<br>>Understood. I¹ll see if packages exist for Amazon Linux and if not, will
<br>>build them ourselves. Our understanding was that Amazon Linux was a
<br>>variant of RHEL and that RHEL packages would work.
<br><br>You would be crazy to use them.
<br><br>>I confirmed that in the case where it¹s not working, no session is being
<br>>created.
<br>>Here¹s the shibd.log with DEBUG logging enabled for:
<br>>OpenSAML.MessageDecoder, Shibboleth.Listener, Shibboleth.RequestMapper,
<br>>and Shibboleth.SessionCache
<br><br>That indicates it's not running the handler, as you originally suggested.
<br>That makes the redirect you're describing to a resource after the POST
<br>something Apache is doing, not the SP. Also, if it doesn't run the
<br>handler, it should be seeing it as a request to a protected resource, and
<br>that should end up as a redirect back to the IdP.
<br><br>>The troubling thing about this is that when the POST request is not being
<br>>handled, it¹s still forwarding to our app which is the one generating the
<br>>/login.act redirect. Shouldn¹t it immediately forward to the IdP again at
<br>>that point?
<br><br>Yes, exactly. And it's not doing that, it's going *directly* to
<br>/login.act, not to / first and then redirecting. You'd see that redirect
<br>in the log. One possibility I guess is a cached redirect, but that's a
<br>really bad thing in and of itself. Either way the whole thing makes no
<br>sense. I have no idea what the POST is doing, but it doesn't appear to be
<br>the SP doing it.
<br><br>I wouldn't trust that entire system at this point.
<br><br>-- Scott
<br><br>--
<br>To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net
<br></p></blockquote></div><br>