[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] RE: AuthenticationMethod / NameIdentifier and Kerberos authentication
Hi John, if your proposed 'pre-authenticated password' class is meant to describe the 'poor man's Kerberos' scenario that Tim and Scott have been discussing, to my mind Liberty already has a class that describes it, namely PasswordProtectedTransport. 'The PasswordProtectedTransport class is identified when a Principal authenticates to an identity provider through the presentation of a password over a protected session.' Admittedly, this class doesn't capture how the IDP validates the password, ie. through a simple lookup or some proxied Kerberos authentication. Would this distinction matter to a Relying Party? If so, perhaps this could be a refinement of the passwordtype just as length is? With respect to ii) below, makes sense to me. Paul >-----Original Message----- >From: John Kemp [mailto:john.kemp@nokia.com] >Sent: Wednesday, April 14, 2004 8:11 AM >To: ext Paul Madsen >Cc: 'Linn, John'; 'Scott Cantor'; 'Tim Alsop'; >security-services@lists.oasis-open.org >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]