[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