Title: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
John,
How would this represent a case where Kerberos was used with non-password based pre-authentication ? The idea of storing the pre-auth type somewhere in the context means that when a new pre-auth type is added to Kerberos to support another hardware device, or some other way to authenticate a user the SAML specification does not need to change - we need to refer to the pre-auth type as a numeric value somewhere in the assertion. The pre-auth types will soon be registered with IANA so we can use them in a normative manner.
Thanks, Tim.
-----Original Message-----
From: John Kemp [mailto:]
Sent: 14 April 2004 13:11
To: ext Paul Madsen
Cc: 'Linn, John'; 'Scott Cantor'; 'Tim Alsop';
Subject: Re: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
Paul,
I agree with that solution, and I think we could also do the following:
i) Create a "pre-authenticated password" class where the
PrincipalAuthMech was password, and the authenticator was set to some value.
ii) Make the SharedSecretDynamicPlaintext element carry a URI which
could indicate which specific method was used (Krb in this case).
What do you think?
- JohnK
ext Paul Madsen wrote:
>Although Liberty didn't define a Kerberos specific context class, the piece
>parts were intended to support the first kerberos scenario described below
>
>The most relevant parts of the statement would be:
>
>1) PrincipalAuthenticationMechanism = Password
>
>2) Authenticator = SharedSecretDynamicPlaintext
>(SharedSecretDynamicPlaintext is defined as 'The local system and
>Authentication Authority share a secret key. The local system uses this to
>encrypt a randomised string to pass to the Authentication Authority'
>
>3) AuthenticatorTransportProtocol = SSL
>
>Paul
>
>
>
>>-----Original Message-----
>>From: Linn, John [mailto:]
>>Sent: Wednesday, April 14, 2004 7:30 AM
>>To: 'Scott Cantor'; 'Tim Alsop'
>>Cc:
>>Subject: RE: [security-services] RE: AuthenticationMethod /
>>NameIdentifier and Kerberos authentication
>>
>>
>>I'll also agree with Scott and JohnK on this. As I see it, designating
>>Kerberos as the method in an assertion issued by a SAML IdP
>>appropriately
>>means that the IdP is issuing that assertion based on a
>>successful Kerberos
>>protocol transaction with the user's client. An alternative
>>where the IdP
>>receives the user's password and itself performs a Kerberos
>>exchange on the
>>user's behalf does involve Kerberos but doesn't constitute
>>Kerberos-based
>>authentication to the IdP in the same sense. It seems a reasonable
>>description for this to annotate a top-level password method
>>indicator with
>>an authentication context describing something like
>>"Kerberos-confirmed",
>>though.
>>
>>--jl
>>
>>-----Original Message-----
>>From: Scott Cantor [mailto:]
>>Sent: Tuesday, April 13, 2004 10:24 PM
>>To: 'Tim Alsop'
>>Cc:
>>Subject: RE: [security-services] RE: AuthenticationMethod /
>>NameIdentifier and Kerberos authentication
>>
>>
>>
>>
>>>Anyway, I think JohnK mentioned using an Auth Context instead
>>>of putting the Kerberos pre-auth in the AuthenticationMethod
>>>statement ? What was the concensus on this, or has it not
>>>been discussed in detail yet ?
>>>
>>>
>>The latter. I think everyone agrees that it makes sense, but I
>>don't know
>>that Liberty has defined any specific classes or statements
>>that deal with
>>Kerberos.
>>
>>
>>
>>>Maybe if Kerberos has been used, but not in the way we prefer
>>>(client in workstation/browser) we could still represent this
>>>method as a Kerberos method, but put something meaningful
>>>into a Context statement that gives more details on how
>>>Kerberos was used to authenticate the user ? That is in
>>>addition to the pre-auth method ? Just a suggestion ... Comments ?
>>>
>>>
>>Right. My criticism pertained to the old method. However, I
>>would be equally
>>opposed to lumping this model into a general Kerberos context
>>class. I think
>>it's closer to a "password" class with specific details
>>provided as to how
>>the server is checking the password for accuracy that mention Kerberos.
>>
>>-- Scott
>>
>>
>>To unsubscribe from this mailing list (and be removed from the
>>roster of the
>>OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/security-services/
>>
>>
>members/leave
>_workgroup.php.
>
>To unsubscribe from this mailing list (and be removed from the roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
>_workgroup.php.
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
>
>
>
>
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
