[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: AW: [ws-sx] Issue 31: Clarification for UsernameToken assertion
Our position would be the same: all properties in WSS Token Profiles should be expressible within WS-SecurityPolicy. UserName Token Profile is just one of good examples to show the need of such granularity of policy requirement. Symon Chang Sr. Security Architect Blue Titan Software -----Original Message----- From: Prateek Mishra [mailto:prateek.mishra@oracle.com] Sent: Friday, February 17, 2006 8:30 AM To: Dittmann, Werner Cc: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org Subject: Re: AW: [ws-sx] Issue 31: Clarification for UsernameToken assertion 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:mgudgin@microsoft.com] >>Gesendet: Freitag, 17. Februar 2006 13:44 >>An: Dittmann, Werner; Marc Goodner; ws-sx@lists.oasis-open.org >>Betreff: RE: [ws-sx] Issue 31: Clarification for >>UsernameToken assertion >> >>Comments inline. >> >>Gudge >> >> >> >>>-----Original Message----- >>>From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] >>>Sent: 16 February 2006 08:08 >>>To: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org >>>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:mgudgin@microsoft.com] >>>>Gesendet: Mittwoch, 15. Februar 2006 00:23 >>>>An: Marc Goodner; Dittmann, Werner; ws-sx@lists.oasis-open.org >>>>Betreff: RE: [ws-sx] Issue 31: Clarification for >>>>UsernameToken assertion >>>> >>>>Comments inline >>>> >>>>Cheers >>>> >>>>Gudge >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Marc Goodner [mailto:mgoodner@microsoft.com] >>>>>Sent: 09 February 2006 20:51 >>>>>To: Dittmann, Werner; ws-sx@lists.oasis-open.org >>>>>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:werner.dittmann@siemens.com] >>>>>Sent: Thursday, February 09, 2006 12:18 AM >>>>>To: ws-sx@lists.oasis-open.org >>>>>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:Werner.Dittmann@siemens.com >>>>>Tel: +49(0)89 636 50265 >>>>>Mobil: +49(0)172 85 85 245 >>>>> >>>>> >>>>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]