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:]
Gesendet: Montag, 27. Februar 2006
01:01
An: Tony Gullotta
Cc: Dittmann, Werner;
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
'
src="gif00040.gif" width=16>"Tony Gullotta"
<>
"Tony Gullotta"
<>
02/24/2006 11:39 AM
To
"Dittmann, Werner" <>,
<>
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:]
Sent: Friday, February 24, 2006 1:57 AM
To: Tony Gullotta;
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:]
>
Gesendet: Donnerstag, 23. Februar 2006 18:55
> An: Dittmann, Werner;
> 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:]
>
Sent: Monday, February 20, 2006 4:22 AM
> To:
> 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;
> > 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:]
>
> > Gesendet: Mittwoch, 15. Februar 2006 00:25
> > > An:
Marc Goodner; Dittmann, Werner;
> > >
Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify token
>
> > assertions
> > >
> > > Comments
inline
> > >
> > > Cheers
> > >
>
> > Gudge
> > >
> > > > -----Original
Message-----
> > > > From: Marc Goodner [mailto:]
>
> > > Sent: 09 February 2006 20:49
> > > > To:
Dittmann, Werner;
> > > > 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:]
>
> > > Sent: Thursday, February 09, 2006 12:17 AM
> > >
> To:
> > > > 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:
>
> > > Tel: +49(0)89 636 50265
> > > > Mobil:
+49(0)172 85 85 245
> > > >
> > >
> >
>
