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

[Bradley Wagner]

Thanks Scott. 






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




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.





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




Got it. Thanks for clarifying.




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





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.





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




Yes, I had tried this.




I enabled a bunch of DEBUG logging in shibd.logger including log4j.category.Shibboleth.RequestMapper but only ever saw the following in the log:





2014-10-14 10:05:18 DEBUG Shibboleth.Listener [1]: dispatching message (default/Login::run::SAML2SI)

2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: validating input

2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: marshalling, deflating, base64-encoding the message

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshal samlp:AuthnRequest

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshalling saml:Issuer

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: starting to marshalling samlp:NameIDPolicy

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: creating root element to marshall

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling namespace attributes for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: marshalling text and child elements for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject

2014-10-14 10:05:18 DEBUG XMLTooling.XMLObject [1]: caching DOM for XMLObject (document is bound)

2014-10-14 10:05:18 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [1]: marshalled message:

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






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?




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

On Tue, Oct 14, 2014 at 10:13 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 10/14/14, 9:57 AM, "Bradley Wagner" <bradley.wagner at hannonhill.com>
> wrote:
>>
>>I was running into an issue where I ultimately determined that the
>>Shibboleth URLs: /Shibboleth.sso/* were not being properly handled by
>>Apache. Every request, including the POST request from the IdP, were
>>being handled as new requests that required authentication instead of a
>>request containing auth information that should have been handled
> 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.
>>The fix, ironically, was to comment out this section of the mod_shib.conf
>>file that shipped with Shibboleth even though the comment says the point
>>of that block is ensure the handle will be accessible.
> 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. 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.
>>but I could never get the handler to be invoked for the Shibboleth.sso
>>URLs. The fix ultimately was to comment out the block in mod_shib.conf at
>>which point it magically started working. I didn't even need a block to
>>explicitly "SetHandler shib" once that initial block was commented out.
> SetHandler is only required in Apache 1.3, it's never been needed since.
> Apache 2+ has always been broken in that it runs *every* handler
> registered until something responds, and it can't be controlled by MIME
> type of URL (this is despite what the docs say). So that's nothing unusual.
> I have no idea about the rest, it isn't consistent with anything I
> understand about Apache.
> 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.
> -- 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/f5d8d042/attachment.html