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: AW: [ws-sx] Issue 30: Need a mechanism to identify token assertions


To put an example on this issue pls have a look to the attached
file. It contains a WSP with several tokens at different levels.

The policy defines two SignedEndorsingSupportTokens (SEST). Each 
SEST signs a different part of the message. Because two SEST are
defined it is save to assume that different tokens are required
to sign the required parts (otherwise one SEST token with two
Header assertions in SignedParts would be used). An implementation
that creates the message according to the policy needs to
associate the different tokens to the correct SEST. As it stands
now this is not possible - the implementation has no "anchor" into
the policy to populate the tokens. IMHO we need to
have a way to identify the tokens (the X.509, Username etc.).

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Dittmann, Werner 
> Gesendet: Donnerstag, 16. Februar 2006 09:30
> An: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org
> Betreff: AW: [ws-sx] Issue 30: Need a mechanism to identify 
> token assertions
> 
> Hmm, I cannot fully agree to that. In particular  at the
> client side we need to know which specific token to use
> to populate a token required by WSP.
> 
> For example, if there are several supporting tokens that each
> require a different X.509 certificate then the implementation must
> somehow be able to identify the token to associate the correct
> certificate to the token. 
> 
> As concrete example: a policy requires two endorsing tokens, each
> endorses different parts of a message. To do so the WSP implementation
> shall be able to identify the tokens and use some method to get the 
> correct certificates to sign the message parts. The WSP method would
> get the token identifier, hands it to the "get certificate" method
> to get the certificate. Agreed, how to link the token identifer
> with the certficates is internal to the implementation (this could
> be even some GUI that interactcts with a person to)
> 
> Or am I somehow off track here?
> 
> Regards,
> Werner
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> > Gesendet: Mittwoch, 15. Februar 2006 00:25
> > An: Marc Goodner; Dittmann, Werner; ws-sx@lists.oasis-open.org
> > Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify 
> > token assertions
> > 
> > Comments inline
> > 
> > Cheers
> > 
> > Gudge 
> > 
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > > Sent: 09 February 2006 20:49
> > > To: Dittmann, Werner; ws-sx@lists.oasis-open.org
> > > Subject: [ws-sx] Issue 30: Need a mechanism to identify token 
> > > assertions
> > > 
> > > This is now logged as issue 30.
> > > 
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/ 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] 
> > > Sent: Thursday, February 09, 2006 12:17 AM
> > > To: ws-sx@lists.oasis-open.org
> > > Cc: Marc Goodner
> > > Subject: NEW Issue: Need a mechanism to identify token assertions
> > > 
> > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON 
> > THREAD UNTIL
> > > THE ISSUE IS ASSIGNED A NUMBER.
> > > 
> > > The issues coordinators will notify the list when that 
> has occurred.
> > > 
> > > Protocol:  ws-sp
> > > ws-securitypolicy-1.2-spec-ed-01-r03-diff.pdf
> > > 
> > > Artifact:  spec
> > > 
> > > Type: design
> > > 
> > > Title: Need a mechanism to identify token assertions
> > > 
> > > Description: 
> > > 
> > > An implementation that uses Security Policy Language has 
> to know how
> > > to populate the required tokens, e.g. UsernameToken or X509
> > > tokens. Because a policy file usually contains several token
> > > assertions there should be a mechanism avaliable to 
> identify a token
> > > assertion.
> > > 
> > > For example if a policy requires two UsernameToken in a supporting
> > > token the application that creates the message needs a way 
> > to link the
> > > different UsernameToken assertions to the user data records that
> > > contains
> > > username, password, etc. To do so the application shall be able to
> > > identify the UsernameToken and use this identifier as a 
> link to the
> > > user data record. 
> > > 
> > > Simliar mechanisms are required to locate the correct X509 
> > certificate
> > > in a keystore, for example. 
> > 
> > [MJG]
> > While I agree that a service needs to be able to distinguish between
> > such tokens and potentially locate such tokens on it's side, I don't
> > believe WS-SecurityPolicy should specify such things. They 
> > are internal
> > implementation details that the client need not be aware of.
> > 
> > > 
> > > Related issues:
> > > none
> > > 
> > > Proposed Resolution:
> > > 
> > > Add an Id or name attribute or to token assertions.  Any 
> other ideas
> > > how to identify token in a Poliy file and associated them 
> with real
> > > user/alias data?
> > > 
> > > Werner Dittmann
> > > Siemens COM MN CC BD TO
> > > mailto:Werner.Dittmann@siemens.com
> > > Tel:   +49(0)89 636 50265
> > > Mobil: +49(0)172 85 85 245
> > > 
> > 
> 
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";
            xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";
            xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
<sp:AsymmetricBinding>
  <wsp:Policy>
    <sp:RecipientToken>
      <wsp:Policy>
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always"; >
          <wsp:Policy>
            <sp:RequireIssuerSerialReference />
          </wsp:Policy>
        </sp:X509Token>
      </wsp:Policy> 
    </sp:RecipientToken>
    <sp:InitiatorToken>
      <wsp:Policy>
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always"; >
          <wsp:Policy>
            <sp:RequireIssuerSerialReference />
          </wsp:Policy>
        </sp:X509Token>
      </wsp:Policy>
    </sp:InitiatorToken>
    <sp:AlgorithmSuite>
      <wsp:Policy>
        <sp:Basic256 />
      </wsp:Policy>
    </sp:AlgorithmSuite>
    <sp:Layout>
      <wsp:Policy>
        <sp:Strict />
      </wsp:Policy>
    </sp:Layout>
    <sp:IncludeTimestamp />
    <sp:EncryptBeforeSigning />
    <sp:EncryptSignature />
    <sp:ProtectTokens />
  </wsp:Policy> 
</sp:AsymmetricBinding>
<sp:Wss11> 
  <wsp:Policy>
    <sp:RequireSignatureConfirmation />
  </wsp:Policy>
</sp:Wss11>
<sp:SignedSupportingTokens>
  <wsp:Policy>
    <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Once"; />
    <sp:AlgorithmSuite>
      <wsp:Policy>
        <sp:Basic256 />
      </wsp:Policy>
    </sp:AlgorithmSuite>
  </wsp:Policy>
</sp:SignedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
  <wsp:Policy>
    <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always"; >
      <wsp:Policy>
        <sp:RequireIssuerSerialReference />
      </wsp:Policy>
    </sp:X509Token>
    <sp:AlgorithmSuite>
      <wsp:Policy>
        <sp:Basic256 />
      </wsp:Policy>
    </sp:AlgorithmSuite>
    <sp:SignedParts>
      <sp:Header Name="Header3" Namespace="uri:namespace_3" />
    </sp:SignedParts> 
  </wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
  <wsp:Policy>
    <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always"; >
      <wsp:Policy>
        <sp:RequireIssuerSerialReference />
      </wsp:Policy>
    </sp:X509Token>
    <sp:AlgorithmSuite>
      <wsp:Policy>
        <sp:Basic256 />
      </wsp:Policy>
    </sp:AlgorithmSuite>
    <sp:SignedParts>
      <sp:Header Name="Header4" Namespace="uri:namespace_4" />
    </sp:SignedParts> 
  </wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
 <sp:SignedParts>
   <sp:Header Name="Header1" Namespace="uri:namespace_1" />
   <sp:Header Name="Header2" Namespace="uri:namespace_2" /> 
   <sp:Body/>
 </sp:SignedParts>
 <sp:EncryptedParts>
   <sp:Header Name="Header2" Namespace="uri:namespace_2" />
   <sp:Body/>
 </sp:EncryptedParts>
</wsp:Policy>


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