Turn off SSO login for some contextClassRef URIs

[Stefan Santesson]

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?

/Stefan



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
>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
>>
>
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net