[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue 101: Need additional SamlToken Assertion Elementsfor Holder-of-Key and Sender-Vouches
Attached is a preliminary proposal for resolution of issue 101. It
for implicit recognition of hk, sv, bearer Assertions that the client can
recognize for the asymm, symm, and transport cases. This is not the only
way that saml tokens can be represented, but it is intended to provide
a starting matrix from which more complex cases could be derived.
(Note: this was done without "Endorsing" tokens, because that would
add extra complexity to sign the signature, which I do not believe
is necessary to accomplish the objective here.)
Please feel free to comment, question, and propose alternatives.
Greg Whitehead wrote:
How do you distinguish between Sender-Vouches and Bearer in that case then? Both are signed. -Greg On 8/11/06 10:09 AM, "Martin Gudgin" <email@example.com> wrote:As I mentioned on the call, I think that Holder-Of-Key is indicated by virtue of the SAML token being used as token that requires proof of key knowledge, for example, [Protection Token], [Endorsing Supporting Tokens], [Signed Endorsing Supporting Tokens]. Similarly, I think Sender-Vouches is indicated by virtue of the SAML token being used as a token that requires signing, for example, [Signed Supporting Tokens] Gudge-----Original Message----- From: Frederick Hirsch [mailto:firstname.lastname@example.org] Sent: 10 August 2006 23:25 To: Marc Goodner Cc: Frederick Hirsch; Rich Levinson; email@example.com Subject: Re: [ws-sx] Issue 101: Need additional SamlToken Assertion Elements for Holder-of-Key and Sender-Vouches +1 on adopting one of Rich's proposals (TC to determine which) This was one of the issues I noted with regard to the Interop document when attempting to craft policy statements for the interop scenarios: "- how to state confirmation method requirement in policy (e.g. HoK for SAML tokens)" See <http://www.oasis-open.org/apps/org/workgroup/ws-sx/email/archives/ 200607/msg00068.html> regards, Frederick Frederick Hirsch Nokia On Aug 9, 2006, at 9:38 AM, ext Marc Goodner wrote:Issue 101. -----Original Message----- From: Rich Levinson [mailto:firstname.lastname@example.org] Sent: Tuesday, August 08, 2006 6:25 PM To: email@example.com; Marc Goodner Subject: NEW Issue: Need additional SamlToken Assertion Elements for Holder-of-Key and Sender-Vouches PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSION THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred. Protocol: ws-sp http://www.oasis-open.org/committees/download.php/18837/ws- securitypolic y-1.2-spec-ed-01-r07.pdf Artifact: spec Type: design Title: Need additional SamlToken Assertion Elements forHolder-of-Key andSender-Vouches Description: Comparable to the level of granularity defined for UsernameToken Assertions (lines 854-861 (NoPassword, HashPassword)) and X509Token Assertions (lines 1004-1024 several token types), the SamlToken Assertion needs token types of sender-vouches and holder-of-key defined. As in the Username and X509 token cases, the WS 1.0 and WS 1.1 Saml Token profiles identify these token types as explicit use cases that the profile supports. http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf see line 495 http://www.oasis-open.org/committees/download.php/16768/wss-v1.1- spec-os -SAMLTokenProfile.pdf see line 672 Related issues: None Proposed Resolution: Add the following lines after line 1322 in section 5.3.8: /sp:SamlToken/wsp:Policy/sp:WssSamlHolderOfKey This optional element identifies that a SAML holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.0, 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlSenderVouches This optional element identifies that a SAMLsender-vouchestoken should be used as defined in [WSS: SAML Token Profile 1.0, 1.1]. The above proposal would require 2 elements to fully define the required token. An alternative approach would be to explicitly define the 2 tokens for all 3 supported versions as follows: /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10HolderOfKey This optional element identifies that a SAML Version 1.1 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.0]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token10SenderVouches This optional element identifies that a SAML Version 1.1 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.0]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11HolderOfKey This optional element identifies that a SAML Version 1.1 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV11Token11SenderVouches This optional element identifies that a SAML Version 1.1 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11HolderOfKey This optional element identifies that a SAML Version 2.0 holder-of-key token should be used as defined in [WSS: SAML Token Profile 1.1]. /sp:SamlToken/wsp:Policy/sp:WssSamlV20Token11SenderVouches This optional element identifies that a SAML Version 2.0 sender-vouches token should be used as defined in [WSS: SAML Token Profile 1.1].
Below are the proposed minimal structures recommended for the three major classes of saml assertions: holder-of-key (hk), sender-vouches (sv), and bearer. Interpretation of the presence of the specified token types in the ws-sp structures below, effectively dictates the type of assertion required. i.e. for example, when the policy is read by the client, and it is found that the InitiatorToken must be WssSamlV11Token10, then it is implicit that holder-of-key is required, because that is the only kind of saml token inherently capable of providing the required encryption and signing (because it contains authorized key material in SubjectConfirmationData that specifies a key the recipient should trust). Really 3 roles here possible from recipient's perspective: trusted-issuer: issuer of assertion requestor: holder of assertion initiator: holder of assertion key if one provided. It should be assumed in all these cases that the recipient is placing primary trust in the key that signs the Assertion. Any secondary keys that are trusted derive the trust from the signer of the Assertion. For example, in each holder-of-key case, the hk Assertion has been signed by a trusted issuer. However, in each of these cases the key in the assertion SubjectConfirmation identifies the key of the "initiator". In the sender-vouches cases, it is the initiator who holds the key that is trusted by the recipient, and the assertion is a SignedSupportingToken that the initiator "signs" when the request is sent on behalf of a requestor. (Note: for transport-sv, the client cert is required because this is the cert that "signs" the assertion.) In the bearer case, it is assumed the assertion is signed by the issuer, and the initiator is simply transmitting the request and the assertion on behalf of the requestor. As such, even though the initiator will generally sign the assertion for coverage, it is just represented in the policy as a SupportingToken (not signed by the initiator in terms of trust). ******************************************************* Asymmetric cases: asymmetric hk: InitiatorToken: WssSamlV11Token10 RecipientToken: WssX509V3Token10 asymmetric sv: InitiatorToken: WssX509V3Token10 RecipientToken: WssX509V3Token10 SignedSupportingToken: WssSamlV11Token10 asymmetric bearer: InitiatorToken: WssX509V3Token10 RecipientToken: WssX509V3Token10 SupportingToken: WssSamlV11Token10 Symmetric cases: symmetric hk: ProtectionToken: WssSamlV11Token11 symmetric sv: ProtectionToken: WssX509V3Token10 SignedSupportingToken: WssSamlV11Token11 symmetric bearer: ProtectionToken: WssX509V3Token10 SupportingToken: WssSamlV11Token11 Transport cases: transport hk: TransportToken: WssSamlV11Token10 transport sv: TransportToken HttpsToken/RequireClientCertificate SignedSupportingToken WssSamlV11Token10 transport bearer: TransportToken: HttpsToken SupportingToken: WssSamlV11Token10 ******************************************************* Note: RecipientToken may not really be needed in the asymmetric case to demonstrate the reqts for the client, but I included it to complete the protection of the messages 2 way, where client just relies on recipient's X509 in general. Note: the asymmetric and transport cases apply to both wssv10 and wssv11. Symmetric is wssv11 only.