Single Sign On (SSO) no longer working

[Cantor, Scott]

On 3/2/16, 10:45 PM, "users on behalf of King, David" <users-bounces at shibboleth.net on behalf of dsmk at bu.edu> wrote:



>Single-sign on no longer works with the 3.2.1 that I am testing.

That's not what the log shows.

>2016-03-03 03:37:53,549 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:350] - Profile Action SelectAuthenticationFlow: Reusing active result authn/Password

That's SSO.

>2016-03-03 03:37:53,552 - WARN [net.shibboleth.idp.session.impl.StorageBackedIdPSession:257] - Skipping update, AuthenticationResult for flow authn/Password in session 67003782855ebd58df489b229583ce286d0823782f986e4c6201ea8a5f7432ac not
>found in storage

There's no way to get that error with trivial storage options like cookies or in-memory short of manipulating state, switching servers, that kind of thing. Even cookie storage is really in-memory at the point that it does anything to the data on the server end.

If it's actually blocking anything though, that would be because the option to mask storage failures isn't on, but that wouldn't get the record updated. Just saying that the logs are explicitly saying it's using an existing result and failing to update the record would only prevent it from not timing out earlier than usual. With the masking on, SSO should be happening, at least until it times out.

> 
>I have reviewed those and don’t see anything that should affect SSO behavior.

No.

> 
>I get the same behavior with both the client and server memory session storage mechanisms so it does not appear to be a client session issue.  I also reviewed the web requests and I do see the cookies.

There's really just flat out no way to get that error with a single server, memory storage, and no restarting. I physically can't think of one. I guess maybe if there was some kind of weird race condition where the record was valid but then expired in the handful of milliseconds later when it gets updated, but that wouldn't be something you'd see much.

> 
>My main question is how to approach debugging this type of issue as I did not see any debugging tips online around session store debugging.

I don't know of any way but a debugger, but you could be turning up a lot more logging at lower layers to see if it indicates anything about what actually didn't work in the storage calls.

>PS:  The relying party.xml changes are only to add elements of the form:
> 
>        <bean parent="RelyingPartyByName"
>          c:relyingPartyIds="#{ {
>            'https://www.concursolutions.com'
>          } }">

Concur does not require you to use a broken NameID Format, you can use any format you want. Thus, touching that file and using an override isn't necessary.

-- Scott