Turn off SSO login for some contextClassRef URIs
cantor.2 at osu.edu
Wed May 20 13:06:04 EDT 2015
On 5/20/15, 4:50 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
>On 5/20/15, 4:22 PM, "Stefan Santesson" <stefan at aaa-sec.com> wrote:
>>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.
Sorry, didn't see your other note...yes, if you're getting loa3-x in that
case, that's what I'd expect. Your Result coming from the flow that
supports both classes is going to have both classes inside it because
that's automatic behavior to handle the cases that are the most common,
without requiring extra code. It wasn't designed around handling actually
distinct classes in one flow, but to handle different classes that really
mean the same thing in one flow.
The built-in flows and core code has/had limitations that made it harder
than intended to override that behavior, and I'm gradually fixing that for
3.2, at which point External code can build a Java Subject to return to
the IdP with exactly the Principals you want to include in the result and
not have it override that on you.
For now, this specific case would be workable by duplicating External with
a copy that handles the second class, so the flow descriptor in each case
won't have both classes. That will still work later too, I'm just working
on fixes that make it unnecessary.
More information about the users