[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: How to get attributes from other categories
Hi Rich, On 13/07/2013 3:48 PM, rich levinson wrote:
To Steven, Mohammad, & TC: At yesterday's meeting, I mentioned that I thought it might be possible to implement the "relationship based access control" reqts using the current 3.0 spec, but also that I have not had time to fully analyze the reqts and the applicability of the soln. In any event, I will explain things as far as I have gotten looking at this capability. The first thing that brought this to my attention was when I was looking at examples using XPathCategory in the 3.0 spec. I was aware that this had something to do w AttributeSelectors, but I was surprised to find one in an AttributeDesignator (in Rule 1 in sec 4.2.4.1): 1090 [f60] <AttributeDesignator 1091 [f61] MustBePresent="false" 1092 [f62] Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 1093 [f63] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector" 1094 [f64] DataType="urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression"/> 1095 [f65] The example is connected to the request in section 4.2.2, and, sure enough, there is an Attribute there that will be resolved w this designator: 963 [e43] <Attribute IncludeInResult="false" 964 [e44] AttributeId="urn:oasis:names:tc:xacml:3.0:content-selector" > 965 [e45] <AttributeValue 966 [e46] XPathCategory="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" 967 [e47] DataType=" urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression" 968 [e48] >md:record/md:patient/md:patientDoB</AttributeValue> 969 [e49] </Attribute> There is nothing particularly remarkable about this particular example, however, it is fairly obvious that the xpathExpression value could apply to the <Content> of any <Attributes> element in the <Request>, simply by changing the value of XPathCategory to point to the Category w the desired value, such as category:action, or category:access-subject. Therefore we have a potential starting point for referencing attributes in some other category than the category that the associated Attribute element is in. i.e. in the above example the Attribute is in the category:resource collection, but its value can be in the <Content> element of either the category:resource collection OR any other <Content> element in some other category:xxx collection, simply by setting the Value of XPathCategory appropriately. There is an additional benefit that the xpath selection mechanism can also be associated w the metadata of the xpathExpression Attribute, which I don't think is the case w the plain vanilla AttributeSelector (but this is a secondary note, not the main point of this discussion). There are a couple of choices that I considered for making this mechanism more general: 1. We could allow XPathCategory to be used w any DataType, in which case the content of the AttributeValue would contain the AttributeId of the desired Attribute in the other Attributes collection-category. I believe this is functionally equivalent to the way the xpathExpression is used, if one considers the path in the content to effectively be the "id" of the attribute. Also, it could be the presence of the XPathCategory attribute that would trigger the semantic interpretation of the value as a reference instead of a normal value.
So if a value fetched by an attribute designator has the XPathCategory XML attribute (not the best name for it, obviously), then the attribute designator instead fetches the attribute nominated by the original value's content from the entity nominated by the XPathCategory XML attribute for the data-type specified by the attribute designator ? For example, if this is the attribute designator: <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="boolean" MustBePresent="false"/> and this is one of the values of the organization attribute in the access-subject: <AttributeValue DataType="boolean" XPathCategory="http://foo.com" >non-profit-organization</AttributeValue> then the attribute designator would fetch the boolean values of the non-profit-organization attribute in the access subject's organization entity. If I've joined the dots correctly, then I see a number of drawbacks: - The content of the attribute value in the access subject (a URI) doesn't conform to it's nominated syntax (boolean). - It's not obvious from the attribute designator what attribute values are being fetched. - The correlations between different attributes of the related entity are lost, just as in attribute flattening. Regards, Steven
2. I can't remember the other choices at the moment, but I think the above was the best one as I recall. So, I think the above should get the basic idea across. I had intended to go thru the emails on attributes of relations in more detail to determine if the above had the potential of meeting the reqts, but I have not had the time to do that, so I am asking the interested parties to that discussion if they think this approach would be viable, and also a path of minimal impact on the existing xacml specs. Thanks, Rich -- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]