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


But how does WS-SP inform the client what to put in the usage? How does the client know that one token's usage is "manager" and the other token's usage is "purchaser"? Right now the only thing WS-SP says is there needs to be two tokens. This requires some sort of out-of-band agreement of what is required.
 
Tony


From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Monday, February 27, 2006 4:33 PM
To: Dittmann, Werner
Cc: Tony Gullotta; ws-sx@lists.oasis-open.org
Subject: Re: AW: [ws-sx] Issue 30: Need a mechanism to identify token assertions

I'm referring to the usage attribute on the STR

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Dittmann, Werner" <werner.dittmann@siemens.com>"Dittmann, Werner" <werner.dittmann@siemens.com>


          "Dittmann, Werner" <werner.dittmann@siemens.com>

          02/27/2006 01:30 AM


To

Anthony Nadalin/Austin/IBM@IBMUS, "Tony Gullotta" <tony.gullotta@soa.com>

cc

<ws-sx@lists.oasis-open.org>

Subject

AW: [ws-sx] Issue 30: Need a mechanism to identify token assertions

To which mechanism are you refering? WS Security defines a "role" attribute in
the Security header according to the SOAP actor/role definitions.

Tony and I are refering to assign a role to the WS SecurityPolicy token assertions to
be able to handle the use cases shown by Tony. This role information is required
by the SecurityPolicy processor to create a message according to the Security
Policy. This is unrelated to the actor/role attribute in the Security header.

Regards,
Werner


Von: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Gesendet:
Montag, 27. Februar 2006 01:01
An:
Tony Gullotta
Cc:
Dittmann, Werner; ws-sx@lists.oasis-open.org
Betreff:
RE: [ws-sx] Issue 30: Need a mechanism to identify token assertions

There already exists a mechanism to do this in WS-Security, I don't think that this TC should create the URI that name these roles.

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Inactive hide details for "Tony Gullotta" <tony.gullotta@soa.com>"Tony Gullotta" <tony.gullotta@soa.com>

                  "Tony Gullotta" <tony.gullotta@soa.com>

                  02/24/2006 11:39 AM

To

"Dittmann, Werner" <werner.dittmann@siemens.com>, <ws-sx@lists.oasis-open.org>
cc
Subject

RE: [ws-sx] Issue 30: Need a mechanism to identify token assertions

We have run into the same use cases. I agree this is something that needs to be addressed. I don't think simply naming the tokens will do it though. Its more like identifying roles for the tokens. So in your example, one token may be for the role "purchaser" and the other for the role "manager". I guess a role is still just a name, but I think semantically its different.

Tony

-----Original Message-----
From: Dittmann, Werner [
mailto:werner.dittmann@siemens.com]
Sent: Friday, February 24, 2006 1:57 AM
To: Tony Gullotta; ws-sx@lists.oasis-open.org
Subject: AW: [ws-sx] Issue 30: Need a mechanism to identify token assertions

Thanks for the better wording to make it more clear.

Yes, somthing like that. Another example would be that a purchase order needs to be signed by two different entities (users). In the sense of "two different entities endorse this message".

Regards,
Werner


> -----Ursprüngliche Nachricht-----
> Von: Tony Gullotta [
mailto:tony.gullotta@soa.com]
> Gesendet: Donnerstag, 23. Februar 2006 18:55
> An: Dittmann, Werner; ws-sx@lists.oasis-open.org
> Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify token
> assertions
>
> Are you trying to indicate that these two tokens represent different
> identities (users)? So you are trying to give consumers an idea of
> which identity must sign? Maybe something like an end-user vs a
> sponsor or application entity?
>
> Tony
>
> -----Original Message-----
> From: Dittmann, Werner [
mailto:werner.dittmann@siemens.com]
> Sent: Monday, February 20, 2006 4:22 AM
> To: ws-sx@lists.oasis-open.org
> 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
> > > >
> > >
> >
>




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