Turn off SSO login for some contextClassRef URIs
stefan at aaa-sec.com
Wed May 20 12:22:12 EDT 2015
Well, it didn¹t work, but sort of. So maybe we can get this to work.
I have 2 ClassRef URI:s, say http://loa3 and http://loa3-x
I¹m running pretty much on the standard config for the IdP.
External authn accepts both http://loa3 and http://loa3-x
In the External servlet I return the DONOTCACHE_KEY attribute set to true
when authn was requested for http://loa3-x
The result is:
1) Authn with http://loa3-x - works fine
2) Authn with http://loa3-x and no ForceAuthn set - works fine (session
was not cached)
3) Authn with http://loa3 and no ForceAuthn set - Works fine. No SSO yet)
4) Authn with http://loa3 and no ForceAuthn set - Works fine. I get SSO
since session was cached.
5) Authn with http://loa3-x and no ForceAuthn set. - Fails. I get SSO
returning http://loa3 in assertion. External is never called.
In Shibboleth2 I used to get an error with standard config if I requested
another ClassRef than was used to cache the session.
What I need is for request 5 to be handed to the External authn servlet,
since there was no session stored associated with http://loa3-x, only with
Is there any hope for me?
On 20/05/15 17:55, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>On 5/20/15, 3:39 PM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>>Is the session cache strictly tied to the ClassRef?
>The AuthenticationResult objects in the session include the Subject and
>the Subject includes all of the custom Principals attached if they
>serialization. A Result can be reused for SSO if it meets the
>of a request.
>>I still want authenticaiton using ClassRef 1 to allow session to be
>>So if authn is requested with ClassRef 2, then that cache from ClassRef 1
>>is not valid.
>That happens regardless. No request for exactly Foo can ever be satisfied
>by a Result that only includes Bar. What you said was the opposite,
>preventing a request for Foo from being satisfied by a previous Result
>including Foo. The only way to prevent that is to not store it at all.
>>If the caching is separated, then I think your solution would work for
>I don't know what you mean by separated. If a Result contains both Foo
>Bar and is stored, then a request for either Foo or Bar can be satisfied
>by it (SSO).
More information about the users