Turn off SSO login for some contextClassRef URIs

Cantor, Scott cantor.2 at osu.edu
Wed May 20 12:50:07 EDT 2015

On 5/20/15, 4:22 PM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:

>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

Unless you pull a snapshot, you are limited here. Right now, doing that 
means that any Result you build out of that flow will include both of 
those classes. There's no way to prevent that. That isn't likely what you 
want, so if you don't switch to a snapshot, you will need to have two 
separate flows defined to the system, each handling one of those classes.

See IDP-699 in Jira.

>5) Authn with http://loa3-x and no ForceAuthn set. - Fails. I get SSO
>returning http://loa3 in assertion. External is never called.

You should not be getting loa3 in the assertion if you're requesting 
loa3-x in the AuthnRequest. However the limitations above mean that the 
Result cached in that case will contain, and support, both loa3 and 
loa3-x, so it should be reusing the Result and returning loa3-x.

>In Shibboleth2 I used to get an error with standard config if I requested
>another ClassRef than was used to cache the session.

This is not about the session, it's about the result(s) inside the 
session, of which there can be any number, all with different properties.

>Is there any hope for me?

Not with one flow, at least without the fixes in svn.

And if you're telling me it's returning a non-matching class in response 
to an AuthnRequest asking for an exact match, then there's a major bug.

-- Scott

More information about the users mailing list