[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 30/07/2013 3:00 PM, rich levinson wrote:
Hi Steven, Apologies for taking so long to get back - as I indicated at the mtg, I was on vacation when this email arrived and simply missed it. I don't think I agree w your analysis/interpretation of my proposal. Let me try doing it more explicitly using your example as a basis. In the policy, the attribute designator contains, as you have suggested: <AttributeDesignator Category="access-subject" AttributeId="organization" DataType="boolean" MustBePresent="false"/> I think where my differs begins in the attribute directly targeted by the designator, which is "organization" in the "access-subject" category. I think the attribute would look like this: <Attribute AttributeId="organization"> <AttributeValue DataType="boolean" XPathCategory="resource" >non-profit-organization</AttributeValue> </Attribute> where the only difference is I have provided the Attribute envelope w the AttributeId, plus I have changed the XPathCategory to something that looks more like a category than what you had there (for which I did not understand the motivation?: did you intend that there be a category called "http://foo.com"? this did not seem to make sense to me.).
I intended that there be another entity represented by an Attributes element and identified by the URI "http://foo.com". This is a specific organization associated with the access subject, which is neither the access-subject nor the resource. I could have conjured up a new, predefined category called "organization", but this assumes that the access-subject can only be associated with one organization. The "Attributes of Relations" thread is, in part, about how to deal with multiple instances of the same kind of entity. In this case, association with more than one organization. If each such organization's Attributes element used the same CategoryId, then this would be interpreted as a request for multiple decisions, which we don't want. So to allow more than one organization entity in the request context, they each need to have a unique CategoryId, which is really an entity identifier in their case, but I don't have the luxury of changing the core schema so CategoryId has to do double duty. Now, if you are only going to use your proposal to reference from one predefined category into another predefined category, then I don't see the value in it. The attribute designator could just be written to directly access the other category instead, e.g.: <AttributeDesignator Category="resource" AttributeId="non-profit-organization" DataType="boolean" MustBePresent="false"/>
In any event, given the way this example is set up, we would now look in the resource category "Attributes" element for an attribute w AttributeId="non-profit-organization" (again, I am just following the example, although the naming does not seem to make sense, which may have something to do w our differing views). <Attributes Category="resource"> <Attribute AttributeId="non-profit-organization"> <AttributeValue DataType="boolean" >true</AttributeValue> </Attribute> </Attributes> So, basically, the motivation here, in the context of this example, is that for some reason, the <Attributes Category="resource"> contains an attribute that the preparer of the <Attributes Category="subject-access"> wants to refer to. Maybe this is just the way they want to set up their policies w the subject-access containing attributes that are associated w other "entities" than the subject-access itself. However, let's leave the motivation until we have a common understanding of the proposed mechanism and then see if it addresses the attributes of relations use case, which would then be the motivation, if appropriate. Now, to address the issues you raised: First the summary statement would say "then the attribute designator would fetch the boolean value(s) of the non-profit-organization attribute in the resource Attributes category of the Request" So the statement begins the same, but now indicates that the actual value is obtained from another Attributes category element.
That was what I intended. The CategoryId of that Attributes element being "http://foo.com".
Now, the issues: * "The content of the attribute value in the access subject (a URI) doesn't conform to it's nominated syntax (boolean)." o You are correct that the DataType in the AttributeValue in the Attribute w AttributeId "organization" does not match the "DataType" of the AttributeValue. However, the reason is that the "XPathCategory" xml attribute of the AttributeValue semantically changes the DataType xml attribute to apply to the target AttributeValue in the Attributes element w the category specified in the current value. i.e. the AttributeValue of the referencing Attribute, which is the one referenced by the AttributeDesignator contains the AttributeId of the Attribute to be found in the Attributes w the category specified by XPathCategory. i.e. The presence of the XPathCategory changes the AttributeValue element from being a value container to being a value "referencer".
I understand that the presence of the XPathCategory XML attribute changes the actual data-type, but it's ugly to have the value proclaim it is one type when it is really a different type. I also realize that you can't fix that without breaking something else.
* "It's not obvious from the attribute designator what attribute values are being fetched." o I disagree. The AttributeDesignator is pointing to the "access-subject" Attributes element, w metadata restrictions of AttributeId and DataType. Because the Attribute contains an XPathCategory this indicates that the target value is not here, but in another Attributes element.
Well that's kind of my point. The AttributeDesignator says get the organization attribute from the access-subject, but the values that are returned are actually from the non-profit-organization attribute in a different category. Or they might actually be from a boolean organization attribute in the access-subject because the values didn't carry the XPathCategory XML attribute. Or they might be from some other attribute entirely because the PEP or PIP put in something other than what you intended. We can't look at an AttributeDesignator and be certain where the values it fetches will be coming from. Control has passed from the policy writer to the PEP and PIP.
This appears to me to be the same as is done w the XPathExpression, where, if XPathCategory is set to anything other than that of the current Attributes element, then the value is retrieved from a different Attributes element. In that case, the XPathExpression, itself, acts as a kind of AttributeId, by pointing to a specific location in an external xml document, namely, the Content "document element", wherever it may be in the overall Request. i.e. in the XPathExpression case, the AttributeDesignator also does not "know" in which Attributes element that the AttributeValue will be found.
Actually it does "know" because the XPathCategory in an xPathExpression value does not affect the processing by the AttributeDesignator. The AttributeDesignator will fetch values of the nominated attribute and data-type from the nominated Attributes element. If those values have the xPathExpression data-type, then they will have an XPathCategory XML attribute, but the AttributeDesignator will just provide these XML attributes in the bag of XACML attribute values that it passes back. It is the XPath-based functions that process the XPathCategory XML attributes. The ContextSelectorId of an AttributeSelector will make the AttributeSelector pay attention to the XPathCategory XML attribute, but section 5.30 of the core specification says that the "XPathCategory attribute of the referenced attribute MUST be equal to the Category attribute of the attribute selector" ruling out the possibility of referencing into a different Attributes element. Thus the indirection you are proposing for the AttributeDesignator does not have a precedent in the processing of xPathExpression values by attribute designators and selectors.
* "The correlations between different attributes of the related entity are lost, just as in attribute flattening." o Ok, I'm not sure what you mean by "attribute flattening", but I do not believe anything is "lost" in my proposal.
Attribute flattening is described in the IPC profile.
The only thing that changes here is that the access is "indirect", just as it is w the XPathExpression that uses XPathCategory and AttributeValue to navigate to the actual value. i.e. in this case the "navigation" is also using XPathCategory to identify the Attributes element, but instead of "XPath'ing" to the target attribute value, it is "AttributeId'ing" to the target AttributeValue. Bottom line is that nothing should be lost because all the info is retained either in the referencing or the referenced Attribute element, and the same metadata controls can be applied as in the direct case. It's just the presence of (the poorly named) XPathCategoryId triggers a slightly more complicated navigation mechanism.
Suppose there is a second boolean attribute of an organization that we want to use in decisions. Let's call it US-organization. We can't reference it using the same access-subject/organization attribute we used for non-profit-organization because that would be ambiguous. We need two access-subject attributes to do the job. Let's call them organization-np and organization-us. Allow that the access subject can be associated with zero, one or more organizations. We can fetch the values the subject's organizations' non-profit-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> We can fetch the values of subject's organizations' US-organization attributes using an attribute designator like: <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> We can ask a question like "is the subject associated with a non-profit organization and associated with a US organization ?" using an expression like: <Apply FunctionId="and"> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-np" DataType="boolean" MustBePresent="false"/> </Apply> <Apply FunctionId="boolean-is-in"> <AttributeValue DataType="boolean">true</AttributeValue> <AttributeDesignator Category="access-subject" AttributeId="organization-us" DataType="boolean" MustBePresent="false"/> </Apply> </Apply> However, we have no way to ask the question "is the subject associated with an organization that is both a non-profit organization and a US organization ?" unless we know for certain that the user is associated with exactly one organization. The above "and" expression will work in that case because we know that any and all values returned for organization-np and organization-us are properties of the same organization. However, when the subject can be associated with one or more organizations we don't know which organization-np values belong with which organization-us values. These are the correlations that get lost with attribute flattening and with your proposal. Regards, Steven
Hopefully this makes the proposal a little more clear. I certainly welcome any issues that you may raise, but I think the current issues are just indicators that clarification of the mechanism was needed as opposed to substantive functional issues, which may still be present, but I don't see them yet. Thanks, Rich On 7/16/2013 8:33 PM, Steven Legg wrote: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, Steven2. 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-- 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]