Our position would be that properties of security tokens should be
expressible within SecurityPolicy,
unless there is a specific security threat that suggests otherwise.
This is specially significant for the UserName and SAML token, both of
which are flexible
XML-based tokens with a number of optional elements/attributes and with
some standard
values for the same.
If we are forced to go down the path where:
<Werner>
This would require that both the client and server are synchronized by
some other means if this cannot be done using a Policy.
</Werner>
even for routine scenarios that have been tested as part of the WSS
interop, then we would be seriously
concerned about the adequacy of the current SecurityPolicy draft.
- prateek
>I was looking at the interop scenarios #1 and #2 where the
>scenarios define wich type of usernametoken parameters/elements
>to use.
>
>If I understand you correctly then
>
>- WSP only defines that a Usernametoken must be included in the
> message and that it shall conform to WSS10 or WSS11.
>
>- which password type to use, if to include an nonce or other
> parameters is outside the scope of WSP and should be determined
> by the implementation in some impl-depended way.
>
>This would require that both the client and server are synchronized
>by some other means if this cannot be done using a Policy.
>
>Interop scenario #2 requires a Usernametoken with cleartext password that is
>encrypted in a second step. Thus if a server application requires
>such a usernametoken to have such a name/password pair then the correct
>setup of the usernametoken have to be synchronized outside Policy.
>We've seen projects that use such a scenario and use PASSWORD_TEXT to
>send some user related information that is used in a service dependend
>manner.
>
>Quote from WSS UsernameToken profile:
>
>Note that PasswordDigest can only be used if the plain text password (or password
>equivalent) is available to both the requestor and the recipient.
>
>IMHO it would simplify the setup of token handling between client
>and server having a more fine grained way to define UT.
>
>Regards,
>Werner
>
>
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Martin Gudgin [mailto:]
>>Gesendet: Freitag, 17. Februar 2006 13:44
>>An: Dittmann, Werner; Marc Goodner;
>>Betreff: RE: [ws-sx] Issue 31: Clarification for
>>UsernameToken assertion
>>
>>Comments inline.
>>
>>Gudge
>>
>>
>>
>>>-----Original Message-----
>>>From: Dittmann, Werner [mailto:]
>>>Sent: 16 February 2006 08:08
>>>To: Martin Gudgin; Marc Goodner;
>>>Subject: AW: [ws-sx] Issue 31: Clarification for
>>>UsernameToken assertion
>>>
>>>I agree to the comment for the server's point of view. But
>>>what about the client? MAybe I'm wrong here but my understanding
>>>of WSP is to define what type of tokens to use, what they are
>>>used for (encrypt, signing, etc.), and which elements they contain.
>>>
>>>
>>[MJG]
>>I'm with you on type and usage. I'm unconvinced it's WSP's
>>job to define what elements they contain. I think that's
>>traditionally been the job of a WSS Token Profile.
>>
>>
>>
>>>In that sense a client that creates a message IMHO needs to
>>>which elements a Usernametoken shall contains, which type of
>>>password to use etc. This cannot be defined as it stands today.
>>>
>>>
>>[MJG]
>>The client needs to be able to construct a token that matches
>>the token profile in use.
>>
>>If the token profile allows for variation, then the client
>>can choose to send any token that matches the profile and the
>>service should accept it.
>>
>>Do you have a specific scenario in mind where a service only
>>supports a subset of a WSS Token Profile?
>>
>>
>>
>>
>>>Regards,
>>>Werner
>>>
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Martin Gudgin [mailto:]
>>>>Gesendet: Mittwoch, 15. Februar 2006 00:23
>>>>An: Marc Goodner; Dittmann, Werner;
>>>>Betreff: RE: [ws-sx] Issue 31: Clarification for
>>>>UsernameToken assertion
>>>>
>>>>Comments inline
>>>>
>>>>Cheers
>>>>
>>>>Gudge
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Marc Goodner [mailto:]
>>>>>Sent: 09 February 2006 20:51
>>>>>To: Dittmann, Werner;
>>>>>Subject: [ws-sx] Issue 31: Clarification for
>>>>>
>>>>>
>>>UsernameToken assertion
>>>
>>>
>>>>>This is now logged as issue 31.
>>>>>
>>>>>Marc Goodner
>>>>>Technical Diplomat
>>>>>Microsoft Corporation
>>>>>Tel: (425) 703-1903
>>>>>Blog: http://spaces.msn.com/mrgoodner/
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Dittmann, Werner [mailto:]
>>>>>Sent: Thursday, February 09, 2006 12:18 AM
>>>>>To:
>>>>>Cc: Marc Goodner
>>>>>Subject: [ws-sx] NEW Issue: Clarification for UsernameToken
>>>>>
>>>>>
>>>>assertion
>>>>
>>>>
>>>>>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: Clarification for UsernameToken assertion
>>>>>
>>>>>Description:
>>>>>
>>>>>The UsernameToken defines additonal (optional) assertions
>>>>>
>>>>>
>>>>that specify
>>>>
>>>>
>>>>>the WSS spec version. IMHO this is not enough to fully specify a
>>>>>UsernameToken. For example a UsernameToken may have a additonal
>>>>>elements such as a creation time. The WSS specs do not
>>>>>
>>>>>
>>>define in any
>>>
>>>
>>>>>way if such elements shall be included or not (some are
>>>>>recommended but
>>>>>no mandated).
>>>>>
>>>>>
>>>>[MJG]
>>>>The assumption is that if you accept, for example,
>>>>
>>>>
>>>UsernameTokens per
>>>
>>>
>>>>WSS 1.0, then you will accept all legal serializations
>>>>
>>>>
>>>>
>>>>>Related issues:
>>>>>none
>>>>>
>>>>>Proposed Resolution:
>>>>>
>>>>>The UsernameToken assertion should be extended to better
>>>>>
>>>>>
>>>reflect the
>>>
>>>
>>>>>WSS username token elements and attributes.
>>>>>
>>>>>Werner Dittmann
>>>>>Siemens COM MN CC BD TO
>>>>>mailto:
>>>>>Tel: +49(0)89 636 50265
>>>>>Mobil: +49(0)172 85 85 245
>>>>>
>>>>>
>>>>>
>
>
>
