[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue 31: Clarification for UsernameToken assertion
[inline] > -----Original Message----- > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] > Sent: 17 February 2006 13:40 > To: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org > Subject: AW: [ws-sx] Issue 31: Clarification for > UsernameToken assertion > > 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. If there are constraints on the UsernameTokens that the service will accept beyond those defined in the WSS Token Profile, then yes, such constraints would have to be conveyed outside of WS-SecurityPolicy. Or the service would use a custom token assertion that conveyed the appropriate constraints e.g. p:MyUsernameTokenThatOnlyAllowsDigestPasswords > > 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. Whether plain text or digest passwords are being used, as a client I'd want to make sure they were not going to be transmitted in the clear before I'd consent to send such a token. > > 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. It seems to me that in most (all?) cases UsernameToken only works if both sides know the username/password combination. > > IMHO it would simplify the setup of token handling between client > and server having a more fine grained way to define UT. I think the level of granularity we have in the spec now hits the 80/20 point. You can choose UsernameToken 1.0 vs 1.1. You can specify RequireDerivedKeys (which implies Nonce, Iterations etc. ). I think adding control attribute values ( e.g. plain/digest passwords ) and element presence ( e.g. Created element ) takes us perilously close to defining a schema language. Which we'd then be tempted to do for all XML based tokens... > > 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]