Turn off SSO login for some contextClassRef URIs

[Stefan Santesson]

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
http://loa3.

Is there any hope for me?


/Stefan






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