[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)
Lets get over this SAML issue. I and others have a requirement as vendors
to support other mechanisms besides SAML, so lets get this in the
requirements document and move on. I don't accept your explanations below,
if you want to get into SAML issues off line I will do so but SAML
has its own set of problems.
This is a open standards process and all we are getting is push back here.
Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
|---------+---------------------------->
| | Trevor Perrin |
| | <trevp@trevp.net>|
| | |
| | 04/30/2003 12:20 |
| | PM |
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Nick Pope <pope@secstan.com>, Anthony Nadalin/Austin/IBM@IBMUS, dss@lists.oasis-open.org |
| cc: |
| Subject: RE: [dss] Representing requestor's identity (As a signed attribute ofsignature) |
>----------------------------------------------------------------------------------------------------------------------------------------------|
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]