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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] Representing requestor's identity (As a signed attributeofsignature)


At 03:36 PM 4/30/2003 +0100, Nick Pope wrote:

>Trevor,
>
>You are wanting to use SAML as a general structure used by DSS.
>
>I strongly suggest that we use the SAML structure when the user is
>authenticated to the DSS using a authentication already wrapped in SAML.  If
>other methods are used for presenting the authentication to the DSS, eg the
>WSS UserNameToken, then this should be provided.

I think there's an advantage to using SAML as a common language that can 
speak about any authentication event.  Then a relying party only has to 
understand SAML.  This is exactly what SAML is designed for.  Otherwise, if 
the DSS server just passes through the user's authentication credentials, 
the relying party needs to understand all sorts of different credentials types.

For example, if the client authenticates to the DSS by presenting a 
Kerberos ticket, and the DSS just embeds the Kerberos ticket in the 
signature, then the relying party won't even be able to decrypt and read 
this ticket, cause it was encrypted to the DSS server.

If the client authenticates with a WSS UsernameToken which the DSS passess 
through, this token may contain the password or its digest, which will 
enable a dictionary attack on the requestor's credentials.

If the client authenticates with an X.509 certificate which is passed 
through, now you're requiring the relying party to parse ASN.1 to read 
certificate contents.

In any case, the embedded credential may or may not contain metadata about 
the authentication event like a SAML Assertion can:
  - who authenticated the client
  - when they authenticated the client
  - a further key which the relying party can authenticate the client with
  - further attributes of the client (his title, his authorizations, etc.)
  - serial number for the authentication so it can be referred to later
  - further advice or conditions about the authentication


>In addition, where it is not required to pass on an identity in the form
>that it was authenticated to DSS there should be a syntax for representing
>the name which allows for the range of name forms that can occur.

I think we should not pass on authentication credentials ("i.e. an identity 
in the form that it was authenticated to DSS").

I agree that we should allow a simple name syntax for expressing the 
requestor's name.  I think we should also allow (but not require) a SAML 
Assertion to be passed in addition to this simple name syntax, when the DSS 
service wants to send details about the authentication.

Trevor 



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