[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Representing requestor's identity
>Are you saying the DSS could be a KDC, and issue a ticket to the client and >then hmac-sign with the symmetric key inside the ticket? If so, since the >DSS is signing with the client's key, wouldn't it be more appropriate to >put the Kerberos ticket inside the signature's ds:KeyInfo? The requirement is to be able to use Kerberos with XML Signature, so the DSS could be a KDC. Its a little more complicated then how you describe. But basically the DSS MUST include an XML Signature <ds:KeyInfo> containing a ticket identifying the security context token that was established >If the schema was general enough that other forms of "authentication >assertions" could be defined later besides SAML, but we initially only >supported SAML, would that be good enough? No, I would like to see the base being: - Simple name string - RFC 3280/X.509 general name (possibly encoded as an LDAP string) - SAML Assertion - WSS UsernameToken - Kerberos - Other name forms to be identified at a later date >I don't see anything in these documents about UsernameTokens being used for >this. Could you elaborate? Username Tokens are one type of security tokens, security tokens may be signed or unsigned, security tokens can be used to provide message authentication. >An authentication assertion needs to represent at least: > - name of subject > - name of issuer > - possibly a cryptographic signature by issuer > - how subject was authenticated > - when subject was authenticated So a signed Username Token can meet your requirements (I don't agree with all items on your list). Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |---------+----------------------------> | | Trevor Perrin | | | <trevp@trevp.net>| | | | | | 04/28/2003 05:21 | | | PM | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Anthony Nadalin/Austin/IBM@IBMUS, dss@lists.oasis-open.org | | cc: | | Subject: RE: [dss] Representing requestor's identity | >----------------------------------------------------------------------------------------------------------------------------------------------| At 04:04 PM 4/28/2003 -0500, Anthony Nadalin wrote: > >I disagree here - I think we should *only* support SAML as far as > >representing the authentication event goes, since it's the only well-known > >technology for doing this (that I'm aware of). WSS UsernameTokens aren't > >intended for this purpose - they don't provide for expressing usernames in > >different "name forms", and they don't provide for saying anything about > >who authenticated the subject, the authentication method, or the > >authentication time. > >Disagree, there are lots of technologies that represent an authentication >event, Kerberos is one of them. Are you saying the DSS could be a KDC, and issue a ticket to the client and then hmac-sign with the symmetric key inside the ticket? If so, since the DSS is signing with the client's key, wouldn't it be more appropriate to put the Kerberos ticket inside the signature's ds:KeyInfo? In other words, the point of identifying the requestor is when the server is signing with its own key, so it needs some extra step to identify the client, but if the server is signing with the client's key, such an extra step isn't needed (for example, if the server had a database of its' clients' private keys which it used to sign, it wouldn't need to identify the requestor either). >Need a extensible mechanism, what you propose is not, so we >need a way expressing name forms including: >- Simple name string >- RFC 3280/X.509 general name (possibly encoded as an LDAP string) >- SAML Assertion >- WSS UsernameToken >- Kerberos >- Other name forms to be identified at a later date If the schema was general enough that other forms of "authentication assertions" could be defined later besides SAML, but we initially only supported SAML, would that be good enough? >Also who ever told you that UsernameTokens aren't intended for this purpose >is wrong, these can and are used as name assertions. I don't see anything in these documents about UsernameTokens being used for this. Could you elaborate? http://www.oasis-open.org/committees/download.php/1044/WSS-SOAPMessageSecurity-11-0303-merged.pdf http://www.oasis-open.org/committees/download.php/1046/WSS-Username-02-0223.pdf An authentication assertion needs to represent at least: - name of subject - name of issuer - possibly a cryptographic signature by issuer - how subject was authenticated - when subject was authenticated Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]