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:
I think where my differs begins in the attribute directly targeted by<AttributeDesignator Category="access-subject" AttributeId="organization" DataType="boolean" MustBePresent="false"/>
the designator, which is "organization" in the "access-subject" category.
I think the attribute would look like this:
where the only difference is I have provided the Attribute envelope<Attribute AttributeId="organization"> <AttributeValue DataType="boolean" XPathCategory="resource" >non-profit-organization</AttributeValue> </Attribute>
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.).
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 theSo the statement begins the same, but now indicates that the actual value
non-profit-organization attribute in the resource Attributes category
of the Request"
is obtained from another Attributes category element.
Now, the issues:
- "The content of the attribute value in the access subject (a
URI)
doesn't conform to it's nominated syntax (boolean)."
- 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".
- "It's not obvious from the attribute designator what attribute
values
are being fetched."
- 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.
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.
- "The correlations between different attributes of the related
entity
are lost, just as in attribute flattening."
- Ok, I'm not sure what you mean by "attribute flattening",
but I do not believe anything is "lost" in my proposal.
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.
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,
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
--
Thanks, Rich
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