OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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


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]
Sent: Wednesday, September 25, 2002 7:00 AM
To: 'Ahmed, Zahid'
Cc: 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]
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