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: AuthenticationMethod / NameIdentifier and Kerberos authentication

Title: RE: AuthenticationMethod / NameIdentifier and Kerberos authentication


I can see that reference to the Kerberos client and where it is installed might need to be made in the WebSSO profile, but this is not very easy because there are many ways to use Kerberos in a web environment and none of them are standards based (as I explained at the recent f2f). One thing for sure, it is not going to be easy to define a generic WebSSO profile that shows how any SAML authentication method can be used. Anyway, I think it is best for me to review your updated web sso profile document and then I will be more able to comment in a constructive manner.

The pre-authentication type determines what Kerberos mechanism was used to authenticate, e.g. userid/password, token, smartcard. Just saying that a Kerberos method has been used is not clear enough. E.g. I can see a situation where an assertion is created referencing a principal and pre-authentication method, and when this assertion is sent to a destination site, if the user authenticated using Kerberos with a smart card different access control decisions can be made than if they authenticated using Kerberos with a userid/password. This is where the padata-type is very useful and the main reason why I suggested we add it to the authentication method in the assertion.



-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: 12 April 2004 21:40
To: 'Tim Alsop'
Cc: 'John Hughes'; security-services@lists.oasis-open.org
Subject: RE: AuthenticationMethod / NameIdentifier and Kerberos authentica tion

> Tim> a real kerberos client is needed to authetnicate the
> user on either workstation, browser, webserver, or somewhere
> else. The reference in SAML doc only needs to show how how
> the principal name from an already authenticated user or
> application can be used to create an assertion and what the
> assertion content looks like. Do you agree ?

I don't think so. At least within the context of the browser profile, what
I'm saying is that using :1510 when the browser is giving the password to
the server is disingenuous. I think that's been discussed.

It seems like the point of the authn assertion and the method/context has to
factor in how the credentials get validated and that has to take into
account the user/client interaction.

So, no, I don't think it's useful to say that a server that gets a password
over HTTP and then gets a TGT should be free to say :1510 instead of
:password or :passwordOverTLS or whatever. If that's what happens, I can't
imagine attaching much importance to that information.

> Tim> It is not the ticket that has principal@realm, since the
> Kerberos ticket is just encrypted data that is used to
> determine the identity (ie. principal name) of the initiator.

I meant colloquially, people tend to say "it's in the ticket", meaning the
credentials that you give to the server.

My point is that how you preauthenticate to get the TGT has nothing to do
with how your principal identity would be expressed. Is it even the case
that your credentials at a service can be used to determine how you
pre-authenticated? I didn't think that was carried along, but maybe I'm

> Tim> does this mean you are proposing a nameid format called
> 1510 instead of 'kerberos' as I indicated above ? Of course I
> can see your point about not wanting to use padata-type for
> NameID and I am happy with that, just wanted to know about
> the kerberos/1510 reference in NameID format.

No, I used kerberos, not 1510.

-- Scott

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