Turn off SSO login for some contextClassRef URIs

[Cantor, Scott]

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 support 
serialization. A Result can be reused for SSO if it meets the requirements 
of a request.

>I still want authenticaiton using ClassRef 1 to allow session to be 
>cached.
>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 me.

I don't know what you mean by separated. If a Result contains both Foo and 
Bar and is stored, then a request for either Foo or Bar can be satisfied 
by it (SSO).

-- Scott