[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] On attributes of relations and SQL profile
Hi Mohammad, On 25/01/2013 6:31 AM, Mohammad Jafari wrote:
I think the issue of “attributes of relations” can be summarized as the need to extend the expressive power of XACML to support: a)“attributes of attributes”, such as: “subject.role.issuer” (the issuer of the attribute “role” for “subject”), “resource.owner.user-id” (user id of the owner of the resource), etc., b)“attributes of multiple attributes/entities”, such as: “(subject,resource.owner).friend.since” (how long the subject has been friends with the owner of the resource), and c)Corresponding “bag” operators. My original point was that probably in next versions of XACML we can consider extending the schema so that instead of flat attributes (i.e. only one level of attributes over the main categories) more complex structures of attributes can be supported (see this email <https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00047.html> and the follow-ups). While my original suggestion was a data model with hierarchical structure for attributes, another alternative is to support tuples and relations in a relational-database-like data model. This has the benefit of matching the existing database data model which is most likely what is used to store complex attributes. Although it was mentioned on the list that we may not want to re-invent SQL because of the complications, I think supporting an SQL-like functionality in XACML is straightforward and does not require extensive changes to the schema, since from a relational algebra point of view, SQL can be thought of as a collection of functions over the data type “relation”, so basically we need to define some new data types and functions. So, a *SQL profile* requires: -A new data type *Tuple* which is a vector (an ordered set) of attributes.
Why would it need to be ordered ? We access attributes by their ID and never by their position or offset. > A *Relation* is a bag of *Tuples*
with the constraint that the data types of the attributes in all of the tuples must be consistent (this is a dynamic constraint but we already have a similar constraint for bags of plain attributes, i.e. that all the attributes in a bag must be of the same type).
I don't see the need for this constraint unless you are planning to drop DataType from attribute designators. Each distinct combination of category, attribute ID and data type is a separate entity. From an XACML functional point of view, two attributes like access-subject/foo/string and access-subject/foo/anyURI are no more related than access-subject/foo/string and access-subject/bar/anyURI. Any relationship is only in the mind of the beholder. Or in other words, I don't see anything wrong with a tuple having both access-subject/foo/string and access-subject/foo/anyURI as attributes.
-A set of relational functions to operate on Relations, e.g. Selection, Projection, Cartesian Product, etc. Note that the format for such functions is slightly different from the existing XACML functions, since for example, Selection requires a condition as an input. We also need a mechanism to refer to a specific attribute within the tuple for such functions. In the following example I have used the XACML “Condition” for the former case, and “TupleAttributeDesignator” for the latter. Back to the IPC example from Erik’s earlier email <https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00057.html>, the condition in the policy rule and the request will look like the following (A:attribute, AV: AttributeValue, DT: DataType). Request: <Request> <Subject> <A//Id="subject:id"//DT="string"> <AV>Alice</AV> </A> <A//Id="Subscriptions"//DT="tuple"> <AV> <A//Id="Device"//DT="string"> <AV>iPhone</AV> </A> <A//Id="Location"//DT="string"> <AV>US</AV> </A> </AV> </A> <A//Id="Subscriptions"//DT="tuple"> <AV> <A//Id="Device"//DT="string"> <AV>XBOX</AV> </A> <A//Id="Location"//DT="string"> <AV>EU</AV> </A> </AV> </A> </Subject> <Resource> <A//Id="resource:id"//DT="string"> <AV>some tune</AV> </Resource> <Action> <A//Id="action:id"//DT="string"> <AV>play</AV> <A//Id="action:device-context"//DT="string"> <AV>iPhone</AV> </Action> <Environment> <A//Id="environment:location"//DT="string"> <AV>EU</AV> </Environment> </Request>
Your attributes are all single-valued. Is that an intentional restriction or just a coincidence ? Apart from syntactic differences, what you have presented above is the same as the compound attribute values I described here: https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00053.html A problem I noted then was that in non-trivial situations duplicates of objects start showing up throughout the request context. Sooner or later you will need to add identifiers to the tuples so that duplicates can be recognized. The request context can also be infinite in theory. While I don't see any obstacles to using embedding as a substitute for foreign keys in tuples, it doesn't look like a good fit to the relational model that you are trying to emulate in XACML. I moved to making the tuples objects on par with the predefined categories (i.e., not embedded) to remove the duplication and make the request context finite. I described this approach in my original response to Richard: https://www.oasis-open.org/apps/org/workgroup/xacml/email/archives/201212/msg00041.html .
Condition: <Condition//FunctionId="integer:greater-than"> <Apply//FunctionId="tuple-bag-size"> <Apply//FunctionId="relation:where"> <Condition//FunctionId="and"> <Apply//FunctionId="string-equal"> <TupleAttributeDesignator//Id="Location"//DT="string"///>
The syntax of this designator doesn't indicate from which tuple in which set of tuples it is extracting the Location/string attribute. That is implied by the enclosing "relation:where" function and its child SubjectAttributeDesignator. Consequently, I don't see how you could express a join between two sets of tuples with this syntax. You would need a "relation:where" function nested within another "relation:where" function with a comparison between the outputs of a pair of tuple designators inside the innermost "relation:where" function. There is no way for the tuple designators to indicate whether they are extracting an attribute from the inner tuple or the outer tuple.
<Apply//FunctionId="string-one-and-only"> <EnvironmentAttributeDesignator//Id="environment:location"//DT="tuple"/>
Shouldn't this be DT=string ?
</Apply> </Apply> <Apply//FunctionId="string-equal"> <TupleAttributeDesignator//Id="Device"//DT="string"///> <Apply//FunctionId="string-one-and-only"> <ActionAttributeDesignator//Id="action:device-context"//DT="tuple"/>
Shouldn't this be DT=string also ?
</Apply> </Apply> </Condition> <SubjectAttributeDesignator//Id="subscriptions"//DT="tuple"/> </Apply> </Apply> <AV//DT="integer">0</AV> </Condition>
By the way, this is how I would solve this example using the iterator expressions and compound attribute values: <ForAny VariableId="$a"> <AttributeDesignator Category="access-subject" AttributeId="subscriptions" DataType="compound-value" MustBePresent="false"/> <Apply FunctionId="and"> <Apply FunctionId="string-at-least-one-member-of"> <TupleAttributeDesignator AttributeId="Location" DataType="string"> <VariableReference VariableId="$a"/> </TupleAttributeDesignator> <AttributeDesignator Category="environment" AttributeId="environment:location" DataType="string" MustBePresent="false"/> </Apply> <Apply FunctionId="string-at-least-one-member-of"> <TupleAttributeDesignator AttributeId="device" DataType="string"> <VariableReference VariableId="$a"/> </TupleAttributeDesignator> <AttributeDesignator Category="action" AttributeId="device:context" DataType="string" MustBePresent="false"/> </Apply> </Apply> </ForAny> My version of TupleAttributeDesignator (I wouldn't actually call it that) extracts the nominated attribute from its child argument, which is required to be a compound-value (i.e., a tuple). In particular, note that I didn't need to invoke the tuple-bag-size and integer-greater-than functions. Regards, Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]