Shibboleth Developers

[Chad La Joie <>]

Tom Scavo wrote:
> On Wed, Mar 5, 2008 at 7:24 AM, Ian Young 
> <>
>  wrote:
> > SAML 1 defines some URIs for authentication methods so that the IdP can
> >  say how things got done.  For example, I've had things set up so that
> >  the authentication method reported is:
> >
> >     urn:oasis:names:tc:SAML:1.0:am:password
> >
> >  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.

It depends on what you mean by different.  They're different in that one 
is more precise than the other but both describe a mechanism used by the 
IdP to authenticate a user.

> >  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.  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, actually it's working exactly how it should.  Mapping a request 
authentication mechanism to a component in the system that can do 
perform that type of authentication.  The IdP doesn't use authn context 
class declarations because, well, they're effectively unusable a 
programmatic layer.

> > The result is that you'd normally end up
> >  sending that second thing above (or some other SAML 2 name) by default
> >  to all SPs, whether you're talking SAML 1 or SAML 2.
>
> 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.  I think that's why some folks would rather carry the
> authentication context as an attribute.  I think that's okay as long
> as it's realized that it has nothing to do with attributes and
> everything to do with authentication.

It isn't what?

> >  I guess that's OK in some sense, but I'm wondering whether there is some
> >  mileage in making it possible for the authentication method indicated to
> >  SAML 1 SPs to be different from the one indicated to SAML 2 SPs
>
> That doesn't make any sense.  Why would you want to have two names to
> describe the same act of authentication?

People use different names for the same thing all the time.  Not 
allowing people to map the different names onto the same processes would 
have been a horrible mistake.

> >  so as to
> >  avoid confusing people who are expecting the old name (not that there
> >  are a huge number of those, I'm sure).
>
> I don't think people are basing access control decisions on
> AuthenticationMethod, so it shouldn't matter.

There applications that do.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch