Unexpected Shibboleth Session Removal

[m***@public.gmane.org]

I am running Alfresco, an open source web based ECM, behind Shibboleth
(Apache 2). Alfresco has quite a few XML HTTP requests (AJAX).
Occasionally, we can't discern any reason as to when, we are seeing a
page fail to completely load. When this happens it appears that the
session has been dropped on the SP side and the SP fails to send a SAML
POST to the IDP. I have exhausted my (limited) knowledge on the subject
and could really use some help troubleshooting the issue.

On failure, the shibd.log on the SP has (identifying information removed):
2014-09-04 07:46:58 INFO Shibboleth.SessionCache [3]: new session
created: ID (_8afc83602ee907b1e83992c61fef98dd) IdP
(https://idp.domain.com/) Protocol(urn:oasis:names:tc:SAML:2.0:protocol)
Address (10.0.135.18)
2014-09-04 07:46:58 DEBUG Shibboleth.SSO.SAML2 [3]: ACS returning via
redirect to: https://server.domain.com/share/page/repository
2014-09-04 07:47:59 INFO Shibboleth.SessionCache [6]: removed session
(_8afc83602ee907b1e83992c61fef98dd)
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
validating input
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
marshalling, deflating, base64-encoding the message
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
marshalled message:
...<cut>
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
message encoded, sending redirect to client
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
validating input
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
marshalling, deflating, base64-encoding the message
2014-09-04 07:47:59 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [6]:
marshalled message:

I notice that a "normal" successful interaction is more like this (note
the SAML2POST):
2014-09-04 11:39:24 INFO Shibboleth.SessionCache [2]: removed session
(_32645b3099cdfa688622954b1ac4a8c9)
2014-09-04 11:39:24 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [2]:
validating input
2014-09-04 11:39:24 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [2]:
marshalling, deflating, base64-encoding the message
2014-09-04 11:39:24 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [2]:
marshalled message:
...<cut>
2014-09-04 11:39:24 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [2]:
message encoded, sending redirect to client
2014-09-04 11:39:27 DEBUG OpenSAML.MessageDecoder.SAML2POST [1]:
validating input
2014-09-04 11:39:27 DEBUG OpenSAML.MessageDecoder.SAML2POST [1]: decoded
SAML message:
...<cut>

The failed authentication shows the following on the IdP side:
15:29:32.931 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:371]
- Error decoding authentication request message
org.opensaml.ws.message.decoder.MessageDecodingException: No SAMLRequest
or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message

The end result is errors like this in the browser:
XMLHttpRequest cannot load
https://idp.server.com/idp/profile/SAML2/Redirect/SSO?SAMLRequest=hZLNbsI...HwkNM%2BoQm3cjleSTf&RelayState=ss%3Amem%3Ae674cf026df847cbc8da26f02260ad0c
<https://idp.stanford.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=hZLNbsIwEIRfJfKdOBhowSKRUjgUiRZEaA%2B9VE68AUuOnXqd%2Frx9A6EtXOjVnv1mZ7RTFJWuedr4vdnAWwPog89KG%2BTHj5g0znArUCE3ogLkvuBZ%2BrDkLIx47ay3hdUkSBHBeWXNzBpsKnAZuHdVwNNmGZO99zVySneY9wprPBgfohemtE6GIBua7VWeWw1%2BHyJaeuAzul5lWxLM24WUEQf0H0jJ%2BhLQPtB2mVJpOE1vQCoHhadZtiLBYh6TVzES8lbmw9GgLEsW5QDsBkZSjpkcDFk5aWWIDSzMAe1jwqL%2BsBdNetFgyxjvMx6NX0iwPmW%2BU0Yqs7teUN6JkN9vt%2Btel%2BgZHB7TtAKSTA8186OxOyv%2BOlb8tE2Sf7vF326n9MyrM675YwtfzNdWq%2BIrSLW2HzMHwkNM%2BoQm3cjleSTf&RelayState=ss%3Amem%3Ae674cf026df847cbc8da26f02260ad0c>.
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://server.domain.com
<https://gsb-content.stanford.edu/>' is therefore not allowed access.

The above error causes all kinds of errors in the browser since it is
usually a JavaScript file that needs to be present for the rest of the
page to function correctly.

During testing I have set my session lifetime to 60 and timeout to 30.
When I raised this up to the defaults (28800 and 3600 respectively), I
was still seeing errors more frequently than every hour.

1. Will raising the lifetime and/or timeout help to solve the problem?
2. Is the session timeout/removal really the cause of my problem?
3. Is there any obvious error, debugging, or configuration that I should
look at to troubleshoot this issue?

Many thanks!

[Cantor, Scott]

Post by m***@public.gmane.org

. No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://server.domain.com is therefore not allowed
access.

I'm not really familiar with these new laughable attempts to "secure"
Javascript that people are apparently using now. It's possible that's
involved and one of the servers in the mix (I assume the SP) has to start
sending some headers to work around it. I don't know what the lack of them
end up leading to. It's connecting to the IdP, but seems to be dropping
the query string I guess.

Of course, even if it made the request, you'd be depending on SSO working
at the IdP since the AJAX call can't execute a real login, and it would
break on the SAML POST binding response the IdP issues. So it really
doesn't matter that much.

Post by m***@public.gmane.org
During testing I have set my session lifetime to 60 and timeout to 30.
When I raised this up to the defaults (28800 and 3600 respectively), I
was still seeing errors more frequently than every hour.
1. Will raising the lifetime and/or timeout help to solve the problem?
2. Is the session timeout/removal really the cause of my problem?

Not in my opinion. Whatever is happening to the session is not a timeout.
There is not a single documented case of the timeouts not working
correctly, and nobody who has claimed there is has ever followed up. I
have no reason to believe it's broken.

Post by m***@public.gmane.org
3. Is there any obvious error, debugging, or configuration that I should
look at to troubleshoot this issue?

Not really. You can look at native.log for indications of session
complaints, but my opinion is that the cookie's just not being sent on
those requests. Short of tracing every bit of traffic until it
demonstrates a failed case, I don't know what else would work.

An issue with third party cookies would be an obvious cause if there are
any additional domains involved in the content containing the AJAX calls.

-- Scott

[mk]

Sorry for the 2nd post. Trying to get this on the mailing list...


Hi.
We are having a very similar problem with Shibboleth right now, where the
cookie appears not be sent on the request after a period of time. We get the
CORS error you displayed.

Have you found a solution to your problem and can you share what that was?

Thanks.



--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Unexpected-Shibboleth-Session-Removal-tp7606463p7607742.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.

[Cantor, Scott]

Post by mk
We are having a very similar problem with Shibboleth right now, where the
cookie appears not be sent on the request after a period of time. We get the
CORS error you displayed.

Then your browser is at fault, but there is no issue to fix here. Not one
case of a "premature" timeout has ever been confirmed.

Post by mk
Have you found a solution to your problem and can you share what that was?

The solution is to stop looking at the session and start looking at the
client. Your problem isn't what you think it is.

-- Scott