Shibboleth Developers

["Scott Cantor" <>]

> >  The SAML 2 spec defines some new names, and in particular defines a
name
> >  for roughly the same thing as the above plus a different one for
> >  password authentication over TLS:
> >
> >
urn:urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
> 
> Those are names for two different things.  They can't be used
> interchangeably.

One is a superset of the other, so of course they can (in the appropriate
SAML version). It's a question of precision.

> >  Now the way the new IdP is built, these names are involved in
> >  configuration of the IdP.
> 
> That's a mistake. Authentication context is not a configuration
> option, it's a runtime consideration.

Actually it's both, which is clear to anybody implementing this. If you
can't know what handler satisfies what context class, then you can't
implement AuthnRequest processing. All the products do it this way, probably
with more complexity to support the additional comparison options, which we
didn't support yet.

I believe Chad also added the additional feature of supplying the actual,
final context class at runtime from the login handler, at my request.

> In addition to the method of
> authentication, authn context has to take into account the strength of
> the credential used, among other things.  Not all passwords are
> created equal.

No, it doesn't *have* to. It can.
 
> That's correct, the version of SAML shouldn't matter.  There's the
> small matter that in SAML V1.1 it's called "AuthenticationMethod",
> which it isn't.

Yeah, it is. It is *not* Authentication Context. It was never meant to be.
It can be overloaded to do that, but that doesn't change its original
purpose.

Ian has a fair point here, but it's not clear whether it's a big deal or
not.

> I think that's why some folks would rather carry the
> authentication context as an attribute.

And you'd be wrong. The reason they prefer it is that products expose
attributes and they don't expose other fields without extra programming.

> I don't think people are basing access control decisions on
> AuthenticationMethod, so it shouldn't matter.

OSU has an application going up this summer that does. We can always just
modify it to check for a 2.0 class string for either SAML version, but I
think Ian is strictly correct.

-- Scott