Skip to Content.
Sympa Menu

shibboleth-dev - Re: authentication methods, SAML 1 vs. SAML 2

Subject: Shibboleth Developers

List archive

Re: authentication methods, SAML 1 vs. SAML 2


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: authentication methods, SAML 1 vs. SAML 2
  • Date: Wed, 5 Mar 2008 08:43:10 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZkL4pWcHURPJGQmjuM40OJXxpXW85AmKqEKl5nuzqZ5pGGJjHfQACd9Swp0D56/FAlGgq+myc0Yiy2U3bn/YwAU9jB6QeWmAs0ZiwDmqq7UrVB58TDVVJie/E5Ln0x4a9r9ebZnot9OudnCX8/ljUCzQZdbBO8qw/1lJcAGYHlk=

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.

> 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.

> 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.

> 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?

> 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.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page