Hi Mohammad, I am not familiar w any specific examples where these subject sub-categories have been used, although they seem like they could be quite useful. I think for the scenario you have described, that I would choose the category:recipient-subject, because, while both the sub-categories apply in the sense that the Consumer System is an intermediary, in the use case you describe the Consumer System also is the intended recipient of the data. Also, I think it is more important that the Consumer System is the intended recipient of the customer's private data, as opposed to the somewhat obvious fact that the Consumer System is an intermediary passing along the user's request, at least from the perspective of the Service Provider. However, I am sure someone could come up w a counter example, so I think the bottom line is that the final choice is a judgement call based on the needs of the participating organizations. A final comment is that this example seems quite analogous to the general OAuth 2.0 scenario, where an end user requests a client application to perform some service whereby the client appl needs to access a resource belonging to the end user that is hosted on some resource server and the client effectively has to pass its own identity info to the authorization server, and the authorization server also needs explicit authorization from the end user to allow this client to access the end user's resource. In the OpenAz project, we have demo'd the use of OAuth2.0 in conjunction w a xacml-based authorization server, with xacml policies that take into account both the end user's identity and the client appl identity, plus the end user's authorization for a particular scope of resources that the client is allowed to access.
http://openaz.svn.sourceforge.net/viewvc/openaz/trunk/openaz/test/doc/test/OAuthSimulator.html Thanks, Rich On 7/23/2013 8:29 PM, Mohammad Jafari wrote: Thanks Rich. Considering the XSPA use case (see below) there is an end user who sends the original access request, and there is also the Consumer Organization who sends the request to acquire the health record from the Service Provider. So, the attributes that appear in the request to the Service Provider PDP include attributes for both the end-user and the Consumer System which sends the request for the data exchange on her/his behalf. For example, the user ID of the end user and the identifier of the Consumer organization, both appear in the request and are both factors in making policy decisions. I had seen the definitions that you have quoted and from the informal explanation it seems to me, it is appropriate to use access-subject for the end user and recipient-subject or intermediate-subject for the Consumer Organization. I am wondering if anyone else have made such distinction in their use-cases and whether they can share how they made the decision to use what category for what kind of subjects. Thanks again. Mohammad From: rich levinson [ mailto:
rich.levinson@oracle.com ] Sent: Tuesday, July 23, 2013 1:14 PM To: Mohammad Jafari Cc:
xacml@lists.oasis-open.org Subject: Re: [xacml] subject categories Hi Mohammad, I am not sure I understand the full extent of your question w/o more context as to what you are trying to achieve. However, it does seem to me that the defns in the core spec, which were also in the 2.0 spec seem fairly obvious, so possibly you missed it in section B.2, lines 5183-5200: Attributes previously placed in the Subject section of a request are placed in an attribute category 5183 which is identical of the subject category in XACML 2.0, as defined below. It is RECOMMENDED that 5184 they are used to list attributes of subjects when authoring XACML 3.0 policies or requests. 5185 This identifier indicates the system entity that initiated the access request. That is, the initial entity in a request chain. If subject category is not specified in XACML 2.0, this is the default translation value. urn:oasis:names:tc:xacml:1.0:subject-category:access-subject This identifier indicates the system entity that will receive the results of the request (used when it is distinct from the access-subject). 5190 urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject This identifier indicates a system entity through which the access request was passed. urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject This identifier indicates a system entity associated with a local or remote codebase that generated the request. Corresponding subject attributes might include the URL from which it was loaded and/or the identity of the code-signer. urn:oasis:names:tc:xacml:1.0:subject-category:codebase This identifier indicates a system entity associated with the computer that initiated the access request. 5198 An example would be an IPsec identity. 5199 urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine Note that the language in the defns uses the term system entity to describe these different categories of subject. This should be taken to mean a distinct entity , whether it be a human actor or a physical machine. Personally, I interpret category to mean a type of object, which probably could be characterized semantically by its own set of allowable attributes. Basically, I consider the category , a collection of attributes w some enterprise or organization semantic meaning, as in this collection of attributes are about something where something is the business or system or organization entity that warrants being described by this particular collection of attributes. (Please pardon the verbose abstraction language I am using as it is intended to be generic and not assuming any particular concrete representation wrt entities .) So, I think the original xacml authors were not trying to specify exactly what the different subject subcategories were actually about, but just giving an indication of a suggested way in which they could be used to characterize entities in the overall network that might be of interest for particular security use cases. Hope this helps, Thanks, Rich On 7/22/2013 11:09 PM, Mohammad Jafari wrote: Hello, As we are trying to update the XSPA XACML profiles, one of the tasks is to support XACML version 3. I noticed that for “subject” attributes, there are now 4 different categories defined in the core. The mandatory category: urn:oasis:names:tc:xacml:1.0:subject-category: access-subject and the optional categories: urn:oasis:names:tc:xacml:1.0:subject-category: recipient-subject urn:oasis:names:tc:xacml:1.0:subject-category: intermediary-subject urn:oasis:names:tc:xacml:1.0:subject-category: requesting-machine But the core does not provide any definition or discussion about the differences between these categories. I was wondering if anyone can comment about the differences or refer me to a definition so that we can make a better decision on which category to use for which attributes. Thanks. Regards, Mohammad -- Thanks, Rich Rich Levinson Internet Standards Security Architect Mobile: +1 978 5055017 Oracle Identity Management 45 Network Drive Burlington, Massachusetts 01803 Oracle is committed to developing practices and products that help protect the environment -- Thanks, Rich Rich Levinson Internet Standards Security Architect Mobile: +1 978 5055017 Oracle Identity Management 45 Network Drive Burlington, Massachusetts 01803 Oracle is committed to developing practices and products that help protect the environment