Turn off SSO login for some contextClassRef URIs
stefan at aaa-sec.com
Wed May 20 12:25:49 EDT 2015
Sorry, sloppy writing.
In test 5 I received the http://loa3-x ClassRef in the assertion, desipte
the fact that no prior authentication with that ClassRef was ever cached.
There must be a security setting to prevent this right?
On 20/05/15 18:22, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>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
>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
>>>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).
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
More information about the users