Single Sign On (SSO) no longer working

[King, David]

Thank you for the confirmation.  It seemed extremely unlikely to me as well.  

I eventually found the problem and it now makes sense.  The work to customize the interface had resulted in setting the donotcache flag on username/password input.  So that sequence of messages indicates that donotcache is set.  Anyway, the problem is fixed.

As for Concur, this is a configuration that I inherited which appears to be based on an IdP v2 entry in the wiki.  Does someone have a simpler v3 configuration?  The config I inherited has a few NameID special cases: Concur, FieldGlass (using a scoped attribute ID with a SAML1 encoding), and Ariba (uppercased username).  

Thanks again for the help,
David

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, March 02, 2016 11:40 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Single Sign On (SSO) no longer working

On 3/2/16, 11:31 PM, "users on behalf of Cantor, Scott" <users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:


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

Verified by looking at the code. It's just impossible for that to fail when it's explicitly saying it found the result in the session to reuse less than a second before that in the log. Not without it having to call some external data store and having that fail in an odd way, i.e. not with simple memory storage involved.

>If it's actually blocking anything though, that would be because the 
>option to mask storage failures isn't on

Also, that won't matter here. This shouldn't even be noticeable as a failure in SSO, the warning message happens in that spot and then it just should proceed (as it says, the update is skipped and that's all).

By that point it should have already decided to do SSO and be done with the login process.

-- Scott

>
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net