Authn Better Matching

[Cantor, Scott]

On 5/14/15, 3:28 PM, "David Walker" <dhwprof at gmail.com> wrote:
>
>Right.  My reading of Marvin's use case was that he wanted to configure the IdP so that a user who had previously authenticated for Silver within a session would be able to access a Bronze-requiring SP later in the session without further authentication.  As you indicated in your earlier note, inexact matching is not the solution for this;

No, it actually *is*, but nothing supports it for the most part. That's exactly the case, to be able to say that you want a "minimum" of Bronze and have Silver come back since in fact Silver is what you did. It's far less nice to have to tell the SP you did Bronze, but that's what exact matching ends up forcing you to do.

> I was suggesting an alternative approach.  I agree that the implementation of such a capability must return Bronze to the Bronze-requiring SP, not Silver, in this example.
> (And, yes, you're right that the MCB does not support inexact matching.)

Yes, that works, but it's suboptimal.

>OK, so it's the supportedPrincipals field of the 
>AuthenticationFlowDescriptor, right?

The supportedPrincipals property is where you define what a flow supports, but it isn't meant to be the determination of what actually occurred (that's the part Marvin and I are discussing how to improve).

That isn't where the comparison rules for inexact matching are defined, that's in a separate file, to define the relationships between the strings independently of where they get used.

But if you're trying to get a Silver flow to handle Bronze, yes, you have to define Bronze as a supported Principal string. You wouldn't need to do that for inexact matching to work since that allows the IdP to know that Silver is "better".

-- Scott