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
- From: "Tony Gullotta" <tony.gullotta@soa.com>
- To: "Anthony Nadalin" <drsecure@us.ibm.com>,"Dittmann, Werner" <werner.dittmann@siemens.com>
- Date: Tue, 28 Feb 2006 08:00:43 -0800
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
I'm referring to the usage attribute on the STR
Anthony Nadalin | Work
512.838.0085 | Cell 512.289.4122
"Dittmann, Werner"
<werner.dittmann@siemens.com>
"Dittmann, Werner"
<werner.dittmann@siemens.com>
02/27/2006 01:30 AM |
|
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
"Tony Gullotta"
<tony.gullotta@soa.com>
"Tony Gullotta" <tony.gullotta@soa.com>
02/24/2006 11:39 AM |
|
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]