[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
All,
Some clarification questions and refinements to the proposal added here.
>Add an optional new element called something like "Tokens" which can
contain one or more tokens
>of any type (including other XML >schemas such as SAML, XrML or XACML).
Tokens has an attribute
>called "Purpose" the value of which is a URN indicating the relationship of
this entity to the message.
>Define a set of URNs to cover the common cases including:
>
>Requester
>Recipient
>Intermediary
>Codebase
>Others could be added as needed.
I think there is value in the concept of using <Tokens> element w.r.t.
qualifying the principal
using the attribute 'Purpose'. In both RPC-style (requestor<->web service)
messaging using
SOAP and distributed, peet-to-peer messaging it may be useful to understand
the context of
processing tokens (e.g., identity and assertion tokens) of participating
principals. However, in
this proposal we have left room for the Purpose attribute to be
application-dependent.
Furthermore, the 4 default Purpose values seem to apply to SOAP message
exchange modes
covering both simple RPC invocations and intermediaries based extended
message exchanges,
and as well as trusted code download scenarios. So that's good set for a
standard set of
purposes.
Container (or as Hal refers to them I believe as "wrappers") modeling of
<Tokens> implies a
container of tokens pertaining to same principal with same purpose. Can we
articulate what is
the value here? E.g., within, a SOAP-based web services activity, it could
be useful to optionally be
able to incrementally include tokens of all participants such that it is
possible to distinguish the
context/purpose of those tokens that represent some identites, assertions,
or binary tokens
(see similar discussion in W3C WS-Arch mailing-list in last one week).
However, the example provided below seems to model the participants tokens
in multiple
instances of the <Tokens> element, where each Tokens instance represents one
principal
with one Purpose, without relating the tokens of these participants
together.
Two questions:
1) Do we need ability to associate the <tokens> together to represent
all participating entities? [For the sake of this discussion, these
entities are being referred to as participants in remaining part of
this discusison]
2) Since additional <tokens> element may be added, wouldn't it make sense to
be
able to optionally encapsulate them together in some security header
child
element? Obviously, the decision of including tokens beyond the target
node
itself is a privacy issue - that could be resolved independent of this
specification.
Context to above questions:
I was wondering if there is way to chain, i.e., associate all web service
participating
principals, at any given instant in the SOAP message traversal, into one
<ParticipantsTokens> element that is contained in the <wsse:Security> header
extension?
<ParticipantsTokens> would be a higher level abstraction to support carrying
tokens
of all web services participants during a SOAP message travesal through
multiple
nodes. This way it will be possible to process the tokens of all principals
participating in a web services activity if they are collected and grouped
together
in one container element. Web service activities could be as simple as a
RPC-based
invocation of a web service or be part of an extended web service message
exchange
that involves intermediaries, peer-to-peer, and varying types of
communication modes.
Implied Requirements:
The ability to model relationships and associations of tokens
w.r.t. a single entity and also w.r.t multiple entities, i.e.,
1) A container model to encapsulate a set of tokens pertaining to
same web service participant/principal would be useful.
2) A container model to encapsulate a set of tokens pertaining to
possibly all the participants/principals participating in
a web service activity would also be higly desirable.
WSS Core Specification has the building blocks for the above two
containers which would be highly desirable to support higher level
abstraction for a range of Web Service SOAP Messaging run-time
problems.
Possible Solution:
An example of the schema definition (this is not tested) that we could use
as
a starting point follows.
<xsd:simpleType name="StandardPurposes">
<xsd:annotation>
<xsd:documentation>
This type represents one of the standard URIs to be used to represent
a
'Purpose' property of Tokens element
</xsd:documentation>
</xsd:annotation>
<xs:restriction base="xsd:anyURI"/>
<enumeration value=<TBD:Requestor_URI>
<enumeration value=<TBD:Recepient_URI>
<enumeration value=<TBD:Intermediary_URI>
<enumeration value=<TBD:Codebase_URI>
<xs:restriction>
</xsd:simpleType>
<xsd:element name="tokensPurpose" type="xsd:anyURI"/>
</xsd:complexType>
<xsd:complexType name="TokensType">
<xsd:annotation>
<xsd:documentation>
This type represents a tokens container/wrapper that encapsulatess
a set of tokens pertaining to same principal with same 'Purpose'
attribute
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:choice>
<xsd:element ref="wsse:UsernameToken"/>
<xsd:element ref="wsse:BinarySecurityToken"/>
<xsd: element ref="saml:Assertion"/>
....
</xsd:choice>
</xsd:sequence>
<xs:element name="Purpose" ref="tokensPurpose"/>
</xsd:complexType>
<xsd:element name="ParticipantsTokens">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Tokens" type="TokensType" minOccurs="1"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
>This is in fact a difference between the two approaches I mentioned, which
I will call the "wrapper" approach
>and the "inheritance" approach. In the wrapper approach, we could agree
that all the tokens within a single
>wrapper refered to the same system entity, whereas tokens appearing in
different wrappers, but with the
>same Purpose value, would (at least potentially) represent different system
entities. This would not be
>possible in the inheritance approach, since each token would be labeled
with its purpose.
Agreed.
W.r.t. abstract token construct carrying a Purpose attribute, currently all
token elements defined
in the Draft 1 of of the Web Services Core specification have an
extensibility mechanism already
available to allow the carrying of additional attributes, e.g., the
<wsse:UsernameToken>:
<xsd:complexType name="UsernameTokenType">
<xsd:annotation>
<xsd:documentation>This type represents a username token per Section
4.1</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Username" type="wsse:AttributedString"/>
<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute ref="wsu:Id"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
Hence, having a 'Purpose' attribute encapsulated in AbtractToken although
could be done, its
purpose is better served in the <Tokens> element as defined above because it
is possible
to characterize the <Tokens> element to be pertaining to a single Purpose
and single
system entity.
Comments?
thanks,
Zahid Ahmed
-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Wednesday, September 25, 2002 11:53 AM
To: 'Munter, Joel D'; 'Oasis Web Services Security'
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
The basic idea is that Authorization Decisions may need to take into account
these multiple types of participants. A number of usecases are available on
the XACML web page, here:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-usecase-01
a.pdf
<http://www.oasis-open.org/committees/xacml/repository/draft-xacml-usecase-0
1a.pdf>
here:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-usecase-01
b.doc
<http://www.oasis-open.org/committees/xacml/repository/draft-xacml-usecase-0
1b.doc>
and here:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-requiremen
ts-01.doc
<http://www.oasis-open.org/committees/xacml/repository/draft-xacml-requireme
nts-01.doc>
In brief,
- Intermediary is required for passive delegation, which is called out in
the WS Roadmap and of course has been a part of many prior AuthZ models,
e.g. DCE and CORBA
- distinct Receiver and Requester is required for Medical records request,
see the XACML HL7 usecases
- Codebase is required by both the Java and .Net authorization models
Hal
-----Original Message-----
From: Munter, Joel D [mailto:joel.d.munter@intel.com]
Sent: Wednesday, September 25, 2002 2:31 PM
To: 'Oasis Web Services Security'
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
yes, sorry that i did not see this before. i would like to see more of a
complete use case or cases leading to these requirements before i agree with
the need though. in other words, what would i do with the information that
you describe that would make ws-security processing better?
joel
-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Wednesday, September 25, 2002 8:18 AM
To: 'Munter, Joel D'; wss@lists.oasis-open.org
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
In my original message of 9/17 I said:
-----
Add an optional new element called something like "Tokens" which can contain
one or more tokens of any type (including other XML schemas such as SAML,
XrML or XACML). Tokens has an attribute called "Purpose" the value of which
is a URN indicating the relationship of this entity to the message. Define a
set of URNs to cover the common cases including:
Requester
Recipient
Intermediary
Codebase
Others could be added as needed.
-----
Based on my experience with other delegation models, I am not proposing the
capability of distingushing one Intermediary from another. Of course this
could be done, but it makes the AuthZ policy model very complex and it is
not clear there are usecases that require it. In any event, anyone who
really needs it could add their own URNs.
It is important to understand that these identities are not the same as SOAP
actors/roles. Purpose generally has to do with senders, whereas actor/role
generally has to do with receivers. Also these tokens will usually be signed
by a trusted authority, so they can be depended on. There is nothing to
prevent any receiver from reading any SOAP header regardless of the
actor/role label. Of course the headers can be encrypted, but in that case,
the actor/role label become irrelevant in practice.
Does that answer your questions?
Hal
-----Original Message-----
From: Munter, Joel D [ mailto:joel.d.munter@intel.com
<mailto:joel.d.munter@intel.com> ]
Sent: Wednesday, September 25, 2002 10:11 AM
To: wss@lists.oasis-open.org
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
hal,
how do i know that the "some URN indicating Requestor" or "some URN
indicating Intermediary" actually represents a requestor or an intermediary?
i apologize if i should have seen this within your proposal but is there
some canonical list of actors, roles or URNtypes that you are proposing?
how do i distinguish one intermediary from another? do we need to identify
the specific purpose of each intermediary?
joel
-----Original Message-----
From: Hal Lockhart [ mailto:hal.lockhart@entegrity.com
<mailto:hal.lockhart@entegrity.com> ]
Sent: Wednesday, September 25, 2002 7:00 AM
To: 'Ahmed, Zahid'
Cc: wss@lists.oasis-open.org <mailto:wss@lists.oasis-open.org>
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
Zahid,
I am not sure if your question refers to the current spec or my proposal,
but as far as I can see it is currently permitted, but it is unclear what
the interpretation of the tokens would be.
Under my proposal, the intention would be to be able to say, "this is the
Requestor", "these are the Intermediaries" and so forth. However, it is
still possible that a given System Entity might be represented by several
Tokens. For example, I might have an X.509 cert and a Kerberos ticket.
This is in fact a difference between the two approaches I mentioned, which I
will call the "wrapper" approach and the "inheritance" approach. In the
wrapper approach, we could agree that all the tokens within a single wrapper
refered to the same system entity, whereas tokens appearing in different
wrappers, but with the same Purpose value, would (at least potentially)
represent different system entities. This would not be possible in the
inheritance approach, since each token would be labeled with its purpose.
These considerations incline me towards the wrapper approach, despite the
sexiness of inheritance as a mechanism. Does anyone object to the idea of
being explicit about which tokens are intended to refer to the same system
entity? I seem to remember some pushback on a related issue pertaining to
the Evidence Element in the SAML AuthZ Dec Req. However, the same
considertions may not apply.
I case the above is not clear, here is the kind of thing I have in mind:
<Tokens Purpose="some URN indicating Requestor">
<UsernameToken> .... <UsernameToken/> <!-- These all
refer to the same entity who is the Requestor -->
<BinarySecurityToken> .{Certificate}... <BinarySecurityToken/>
<Tokens/>
<Tokens Purpose="some URN indicating Intermediary">
<BinarySecurityToken> ..{certificate}.. <BinarySecurityToken/>
<!-- These all refer to the same entity who is one of the Intemediaries -->
<BinarySecurityToken> ..[kerberos ticket}.. <BinarySecurityToken/>
<Tokens/>
<Tokens Purpose="some URN indicating Intermediary">
<UsernameToken> .... <UsernameToken/>> <!-- These all
refer to the same entity who is (presumed to be) a different Intemediary -->
<BinarySecurityToken> ..{kerberos ticket}.. <BinarySecurityToken/>
<Tokens/>
Hal
-----Original Message-----
From: Ahmed, Zahid [ mailto:zahid.ahmed@commerceone.com
<mailto:zahid.ahmed@commerceone.com> ]
Sent: Tuesday, September 24, 2002 11:19 AM
To: Hal Lockhart; wss@lists.oasis-open.org
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
>Add an optional new element called something like "Tokens" which can
contain one or more tokens of any type
>(including other XML schemas such as SAML, XrML or XACML). Tokens has an
attribute called "Purpose"
>the value of which is a URN indicating the relationship of this entity to
the message.
Hal,
I agree with this proposal. However can there be multiple <Tokens> elements
within
a SOAP security header extension?
thanks,
Zahid
At 07:21 AM 09/17/2002, Hal Lockhart wrote:
This is the idea I introduced near the end of the F2F.
Requirement
WS-Security proposes a SOAP Security Header that can contain tokens of
various kinds which represent the identity and attributes of some system
entity. I cannot find any explicit statement of the intended semantics of
these tokens with respect to the particular message they appear in, however
from the context it appears the intention is that the token represent the
identity of the sender. It is also possible that the intention is that this
semantic not be specified by WS-Security, but in some other, future
specification. However, neither intention covers the cases where two or more
system entities with different relationships to the message must be
represented and distinguished.
Some example usecases where this is applies include:
1) Patient requests his or her medical records be sent to specialist
physician. Authorization decisions depends on identity and attributes of
both Requester and Recipient, who are not the same entity.
2) Passive delegation requires that authorization depend on the identity and
attributes of the Requester and any Intermediaries.
3) Some authorization models, e.g. Java and .Net, consider the Principal
identity associated with the local or remote Codebase from which the request
originates as well as that of the Requestor.
Possible Approach
What is needed is some way to optionally label each token as to the Purpose
of the system entity being identified. Associating the token with the
Requester should remain the default, if the Purpose label is omitted.
This "Purpose" should not be confused with the SOAP actor/role, which
specifies who should READ various parts of the header, not the parties on
whose identities and attributes authorization will be based.
There is more than one way to do this given the schemas already defined or
proposed. Here is one possible approach.
Add an optional new element called something like "Tokens" which can contain
one or more tokens of any type (including other XML schemas such as SAML,
XrML or XACML). Tokens has an attribute called "Purpose" the value of which
is a URN indicating the relationship of this entity to the message. Define a
set of URNs to cover the common cases including:
Requester
Recipient
Intermediary
Codebase
Others could be added as needed. All the tokens within a given "Tokens"
element would be deemed to have the same purpose, but not necessarily refer
to the same system entity. (Consider multiple intermediaries, multiple
codebases, etc.) If "Tokens" is not specified, Requestor would be the
default Purpose.
Another technical approach would be to define a Token abstract and derive
UsernameToken, BinarySecurityToken and TokenReference from it. Also derive a
new type NativeToken (XMLToken is illegal) to serve as a wrapper for XML
tokens. The Token abstract would carry the Purpose attribute, as above. This
is a more extensive change to the schema currently proposed.
One difference between the two would be that in the latter approach, it
would be necessary to allow duplicate Purpose values on different tokens
within the same Security header. With the former approach, this could be
prohibited if it was deemed desirable to do so.
I am not hard over on the names Token or Purpose. Any scheme which meets the
requirements is fine with me. The name Purpose was chosen mainly because the
obvious choice "role" is already being used in several different ways and I
did not want to add to the confusion.
However, it is possible that this scheme could also be used in ways that do
not involve representing an identity associated with the origin of the
message. In this case, the use of a vague term such as Purpose would be an
advantage.
For example, a response message could contain a XACML policy or XrML license
which indicates the authorization rules to be applied to the content in the
message body (which presumably would be encrypted) by the Recipient. In this
case the Purpose might be something like "authorization policy".
Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC