Shibboleth SP mod_shib module not handling Shibboleth.sso URLs and looping

Tue Oct 14 13:14:04 EDT 2014

Thanks again Scott. I appreciate all of the prompt and thorough responses.

> 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.

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:

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"

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"

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"

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”

And I see the principal (REDACTED above) in both requests.

> 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.

Yep, agreed. I too have never understood how to use them effectively.

> If they don’t work, I would just get rid of them. That simple, really.

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.

Would it be worth noting that these directives may or may not be necessary but should probably be left off by default?

I’d be happy to make a commit to that effect.

Thanks!

On Tue, Oct 14, 2014 at 12:59 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 10/14/14, 12:42 PM, "Bradley Wagner" <bradley.wagner at hannonhill.com>
> wrote:
>>
>>Understood. I¹ll see if packages exist for Amazon Linux and if not, will
>>build them ourselves. Our understanding was that Amazon Linux was a
>>variant of RHEL and that RHEL packages would work.
> You would be crazy to use them.
>>I confirmed that in the case where it¹s not working, no session is being
>>created.
>>Here¹s the shibd.log with DEBUG logging enabled for:
>>OpenSAML.MessageDecoder, Shibboleth.Listener, Shibboleth.RequestMapper,
>>and Shibboleth.SessionCache
> That indicates it's not running the handler, as you originally suggested.
> That makes the redirect you're describing to a resource after the POST
> something Apache is doing, not the SP. Also, if it doesn't run the
> handler, it should be seeing it as a request to a protected resource, and
> that should end up as a redirect back to the IdP.
>>The troubling thing about this is that when the POST request is not being
>>handled, it¹s still forwarding to our app which is the one generating the
>>/login.act redirect. Shouldn¹t it immediately forward to the IdP again at
>>that point?
> 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. Either way the whole thing makes no
> sense. I have no idea what the POST is doing, but it doesn't appear to be
> the SP doing it.
> I wouldn't trust that entire system at this point.
> -- 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/20141014/cf51fe35/attachment.html 