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

[Bradley Wagner]

Hi,

I spent the better part of a day troubleshooting this, so I figured it
would be worth getting to the bottom of this.

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

I confirmed this by looking a shibd.log and noticed that the message
received during the POST back from the IdP was never being unpacked and was
instead just generating a new authentication redirect to the IdP.

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.

#
# Ensures handler will be accessible.
#
#<Location /Shibboleth.sso>
# Satisfy Any
# Allow from all
#</Location>

When it was uncommented, I tried all all kinds of things including adding a
block to my Virtual Host:

<Location /Shibboleth.sso>
SetHandler shib
</Location>

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.

Any ideas?

Here are some other details of my config:

I'm using mod_shib in Apache 2.2.17 and Shibboleth 2.5.3.

My /etc/httpd/conf.d/mod_shib.conf file:

LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_22.so

#
# Ensures handler will be accessible.
#
#<Location /Shibboleth.sso>
# Satisfy Any
# Allow from all
# SetHandler shib
#</Location>

#
# Used for example style sheet in error templates.
#
<IfModule mod_alias.c>
<Location /shibboleth-sp>
Satisfy Any
Allow from all
</Location>
Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css
</IfModule>

I've got the following VirtualHost set-up in my
/etc/httpd/conf.d/proxies.conf file:

<VirtualHost *:443>
ServerName ourdomain.com
SSLEngine on
SSLProtocol all
SSLCertificateFile /path/to/crt
SSLCertificateKeyFile /path/to/key
SSLCertificateChainFile /path/to/chain

<Location />
AuthType shibboleth
ShibRequestSetting requireSession 1
require valid-user
</Location>

ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/
</VirtualHost>

[Peter Schober]

Post by Bradley Wagner
I'm using mod_shib in Apache 2.2.17 and Shibboleth 2.5.3.

Platform, OS, distribution? OS/distribution-supplied webserver?
Shib RPMs from the OBS repository or custom (re-)built ones?
-peter

[Bradley Wagner]

Thanks Peter.

Platform, OS, distribution? 

Amazon Linux AMI release 2011.02.1.1 (beta)

OS/distribution-supplied webserver?

Yes, Apache 2.2.17 from Amazon Linux’s package manager.

Shib RPMs from the OBS repository or custom (re-)built ones?

Used these: http://download.opensuse.org/repositories/security://shibboleth/RHEL_6/

On Tue, Oct 14, 2014 at 10:01 AM, Peter Schober

Post by Bradley Wagner
I'm using mod_shib in Apache 2.2.17 and Shibboleth 2.5.3.

Platform, OS, distribution? OS/distribution-supplied webserver?
Shib RPMs from the OBS repository or custom (re-)built ones?
-peter
--

[Cantor, Scott]

Post by Bradley Wagner

Post by Peter Schober
Shib RPMs from the OBS repository or custom (re-)built ones?

http://download.opensuse.org/repositories/security://shibboleth/RHEL_6/

Packages on Linux are 100% non-portable and should never be used on a
different distribution no matter how similar it is. CentOS and RHEL are
exceptions because CentOS is just a rebuild of the RHEL packages.

-- Scott

[Peter Schober]

Post by Bradley Wagner
Amazon Linux AMI release 2011.02.1.1 (beta)

Not the version you're using but the advice probably still applies:
http://shibboleth.net/pipermail/users/2014-April/015191.html
-peter

[Cantor, Scott]

Post by Bradley Wagner
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.

Post by Bradley Wagner
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.

Post by Bradley Wagner
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

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

Post by Bradley Wagner
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.

Post by Bradley Wagner
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.

Post by Bradley Wagner
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
--

[Bradley Wagner]

So here’s the sequence of requests when it loops and the block is uncommented:




GET / - 302 redirects to the IdP.

<requests to the IdP>


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.

GET /a-url-in-my-app - 302 redirects to the IdP with a new auth request.

<requests to the IdP>




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.




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.




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.




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.




Thanks again for the help on this. It feels like something subtler than a library mismatch but perhaps not.

On Tue, Oct 14, 2014 at 11:07 AM, Bradley Wagner

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

Post by Bradley Wagner
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.

Post by Bradley Wagner
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.

Post by Bradley Wagner
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
--

[Cantor, Scott]

Post by Bradley Wagner
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.
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.

I would assume that in both cases it should log the creation of the
session, in which case the problem is that Apache is doing something wrong
and overwiting the response headers it's trying to set.

Post by Bradley Wagner
Thanks again for the help on this. It feels like something subtler than a
library mismatch but perhaps not.

You cannot use packages on the wrong OS, period.

-- Scott

[Bradley Wagner]

http://shibboleth.net/pipermail/users/2014-April/015191.html




Thanks. We’re using the RHEL6 packages but it’s possible that we’re running into something similar.

Post by Cantor, Scott
You cannot use packages on the wrong OS, period.

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.




If you think rebuilding Shibboleth before trying to troubleshoot this further is the way to go, we can certainly do that.

Post by Cantor, Scott
I would assume that in both cases it should log the creation of the session

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





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

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




and here’s the Apache request log:





66.194.102.6 - - [14/Oct/2014:11:18:17 -0500] "GET / HTTP/1.1" 302 927 "-" "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:18:19 -0500] "POST /Shibboleth.sso/SAML2/POST 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 - - [14/Oct/2014:11:18:19 -0500] "GET /login.act HTTP/1.1" 302 925 "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”




When it works, I see the following...




shibd.log:





2014-10-14 11:26:03 DEBUG Shibboleth.Listener [2]: dispatching message (default/Login::run::SAML2SI)

2014-10-14 11:26:05 DEBUG Shibboleth.Listener [1]: dispatching message (default/SAML2/POST)

2014-10-14 11:26:05 INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.4

2014-10-14 11:26:05 INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:0.9.2342.19200300.100.1.3

2014-10-14 11:26:05 INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.42

2014-10-14 11:26:05 INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.5.4.3

2014-10-14 11:26:05 INFO Shibboleth.AttributeExtractor.XML [1]: skipping unmapped SAML 2.0 Attribute with Name: urn:oid:2.16.840.1.113730.3.1.241

2014-10-14 11:26:05 DEBUG Shibboleth.SessionCache [1]: creating new session

2014-10-14 11:26:05 DEBUG Shibboleth.SessionCache [1]: storing new session...

2014-10-14 11:26:05 INFO Shibboleth.SessionCache [1]: new session created: ID (_<REDACTED>) IdP (https://<REDACTED>/idp/shibboleth) Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address (66.194.102.6)






Apache request log:





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”




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?




Do I need to tweak my require here to be something other than valid-user?





  <Location />

    AuthType shibboleth

    ShibRequestSetting requireSession 1

    require valid-user

  </Location>






So the two issues that remain when that <Location> block is left uncommented:


The POST /Shibboleth.sso/SAML2/POST requests don’t appear to be handled at least according to the Shib logs.

Even though the POST requests aren’t being handled, it appears to be passing traffic through to our app which is returning a redirect to /login.act. That request that generates another auth request with the IdP.

Thanks!

Post by Cantor, Scott

Post by Bradley Wagner
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.
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.

I would assume that in both cases it should log the creation of the
session, in which case the problem is that Apache is doing something wrong
and overwiting the response headers it's trying to set.

Post by Bradley Wagner
Thanks again for the help on this. It feels like something subtler than a
library mismatch but perhaps not.

You cannot use packages on the wrong OS, period.
-- Scott
--

[Cantor, Scott]

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

[Cantor, Scott]

Post by Cantor, Scott
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.

Actually, given the whole picture, its clear the SP is having no general
issue seeing this as a handler request and implementing that. 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.

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

-- Scott

[Bradley Wagner]

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!

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

[Cantor, Scott]

Post by Bradley Wagner
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.

If you want to file a bug, attach a summary of the Apache log in the
failing case, and I will eventually revisit the commands at some future
date.

-- Scott

[Bradley Wagner]

Sure. Will do.

Post by Cantor, Scott

Post by Bradley Wagner
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.

If you want to file a bug, attach a summary of the Apache log in the
failing case, and I will eventually revisit the commands at some future
date.
-- Scott
--

[Bradley Wagner]

Which project would this fall under? https://issues.shibboleth.net/jira/secure/Dashboard.jspa

Post by Cantor, Scott

Post by Bradley Wagner
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.

If you want to file a bug, attach a summary of the Apache log in the
failing case, and I will eventually revisit the commands at some future
date.
-- Scott
--

[Cantor, Scott]

Post by Bradley Wagner
Which project would this fall under?
https://issues.shibboleth.net/jira/secure/Dashboard.jspa

Shibboleth SP

-- Scott

[Bradley Wagner]

Thanks Scott. Let me know if you need any other info. I realize this is an edge case and not a high priority. Just want to make sure others don’t get bit by this in the future.




https://issues.shibboleth.net/jira/browse/SSPCPP-633

Post by Cantor, Scott

Post by Bradley Wagner
Which project would this fall under?
https://issues.shibboleth.net/jira/secure/Dashboard.jspa

Shibboleth SP
-- Scott
--