OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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:jlinn@rsasecurity.com]
>>Sent: Wednesday, April 14, 2004 7:30 AM
>>To: 'Scott Cantor'; 'Tim Alsop'
>>Cc: security-services@lists.oasis-open.org
>>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:cantor.2@osu.edu]
>>Sent: Tuesday, April 13, 2004 10:24 PM
>>To: 'Tim Alsop'
>>Cc: security-services@lists.oasis-open.org
>>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.
>
>
>  
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]