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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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 provides
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.

    Thanks,
    Rich


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" <mgudgin@microsoft.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:frederick.hirsch@nokia.com]
Sent: 10 August 2006 23:25
To: Marc Goodner
Cc: Frederick Hirsch; Rich Levinson; ws-sx@lists.oasis-open.org
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:rich.levinson@oracle.com]
Sent: Tuesday, August 08, 2006 6:25 PM
To: ws-sx@lists.oasis-open.org; 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 for
        
Holder-of-Key and
      
Sender-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 SAML
        
sender-vouches
      
token 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.



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