Authn Better Matching
cantor.2 at osu.edu
Mon May 4 11:55:36 EDT 2015
On 5/4/15, 10:58 AM, "Marvin Addison" <marvin.addison at gmail.com> wrote:
>I can infer from the message that the matching semantics are exact, which presumably doesn't engage inexact matching.
That's correct. "better" is referring to that specific SAML operator.
> But I would think this is exactly the kind of case for which inexact and better matching in particular is intended to support. I think I can get this to work another way, but I'd like to understand why this doesn't work; and if it doesn't work by design, what kinds of cases it's intended to support.
It supports an SP requesting "better". SAML is *not* designed to make these determinations at the IdP because it assumes that an SP that cares would care enough to ask.
There isn't currently anything in the IdP that lets you spoof inexact matching. Not exactly an oversight, I thought about it, but I didn't implement anything. The defaultAuthenticationMethod setting carried over from V2 maps to "exact".
I'm not sure I do understand the use case you're getting at, I tend to be pretty confused by what people are really trying to use all this stuff for. All I wanted to do was make the SAML operators work in theory, which is a far cry from understanding how anybody would use them.
Maybe if we started with the question of when exactly the bronze flow would be expected to run at all?
>FWIW, my test SP simply has the following configuration directive in the Apache config:
The Shibboleth SP supports the other operators via authnContextComparison.
More information about the users