Turn off SSO login for some contextClassRef URIs

[Cantor, Scott]

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.

-- Scott