OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

    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

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:


and this is one of the values of the organization attribute in the


then the attribute designator would fetch the boolean values of the
non-profit-organization attribute in the access subject's organization

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.


 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

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]