XACML and RDF
This page describes possible approaches to applying semantic web technologies to XACML. By "semantic web technologies" we mean, briefly, RDF for data representation, OWL for ontology definition and reasoning, and SPARQL for data queries.
Although rules are often considered an essential component of the semantic web, we leave for a another discussion the opportunities for establishing touchpoints between the XACML policy language and the generic family of rule languages standardized by the Rule Interchange Format (RIF).
We do not preclude the possibility of further unification of these matters under the rubric of Common Logic (ISO/IEC 24707) or any of the various standard representations defined by that standard.
This discussion focuses primarily on the use of the RDF vocabulary description language (RDFS). However, the techniques are applicable also to OWL ontology definitions. The examples use Turtle syntax, with the following prefixes defined:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix xacml: <to-be-determined-uri-stem#> .
The possible work items of the TC include:
- Normative formal RDF/OWL definitions of the XACML ontology (attributes, resources, subjects, actions).
- Add provisions in the request/response syntax to identify resources, subjects, and actions by URI alone.
- Extend the policy language to test ontological conditions such as subclass membership and class relations.
- Guidelines or best practices for semantically-enabled context handlers, including 2-way translation of XACML request context to RDF model.
- Profile describing the use of RDF for attribute metadata.
XACML attributes as RDF properties
First we can define XACML attributes (in general) as subproperties of RDF properties.
xacml:Attribute rdfs:subPropertyOf rdf:Property .
The XACML rule and request syntax is primarily concerned with attributes, which correspond to RDF properties. Both are named with URIs. So it is easy to write an RDFS property definition for each XACML attribute.
<urn:oasis:names:tc:xacml:1.0:resource:resource-id> a xacml:Attribute .
(Because xacml:Attribute is a subproperty of rdf:Property, <urn:oasis:names:tc:xacml:1.0:resource:resource-id> is also an rdf:Property.)
Attributes/properties of what?
We are not used to attributes or properties floating about freely--we want to know, attributes of what? XACML is very loosely typed--there are four categories that can be considered as classes. This is not a defect in XACML; in fact, it could be considered a strength because it allows great flexibility in interpretation and implementation. On the other hand, in many situations one wants to make rules for particular types of resources or subjects. In those cases, some sort of class system is necessary. We can easily put the XACML framework into RDF by calling these categories subclasses of rdfs:Resource.
xacml:Resource rdfs:subClassOf rdfs:Resource . xacml:Subject rdfs:subClassOf rdfs:Resource . xacml:Action rdfs:subClassOf rdfs:Resource . xacml:Environment rdfs:subClassof rdfs:Resource .
Now we can associate properties to each class (or category) like so:
<urn:oasis:names:tc:xacml:1.0:resource:resource-id> a xacml:Attribute ; rdfs:domain xacml:Resource rdfs:range <http://www.w3.org/2001/XMLSchema#string> ; rdfs:range <http://www.w3.org/2001/XMLSchema#anyURI> .
This says that resource-id is a property of the (XACML) class, xacml:Resource, and can take values from the ranges of string and anyURI.
We can formalize things a bit more by declaring the domains of xacml:Attribute:
xacml:Attribute rdfs:domain xacml:Resource , xacml:Subject , xacml:Action , xacml:Environment .
This just says that xacml attributes properly belong to xacml classes.
In any particular domain of application for XACML there is an underlying ontology--either implicit or explicit. A complete XACML attribute vocabulary can be generated simply by assigning URIs to the classes and properties of the native ontology.
The equivalence of XACML attributes to RDF properties means we can freely borrow property definitions from any other RDF vocabulary. One useful property is rdf:type, which can be used to specify the type of object in XACML exchanges.
Suppose we have an enterprise definition of Document defined by the uri, <http://example.org/Document>. We have policies that apply to documents (but not to other types of resources, like buildings or hardware). The Target for such a policy might include a Match element like
<Match MatchId="anyURI-equal"> <AttributeDesignator AttributeId="&rdf;type"/> <AttributeValue DataType="anyURI">http://example.org/Document</AttributeValue> </Match>
This allows us to easily re-use our enterprise ontology in access control rules without inventing new attributes, and mapping between enterprise definitions and XACML definitions.
Identifying XACML objects with URIs
The XACML request and response XML syntax identifies objects (resources, subjects, actions) by their attributes. This is "identification by predication". You can't say, in XACML, "the subject, John Doe"; you must say "the subject whose name is 'John Doe'".
In a semantic environment, anything of interest can have a URI that represents the thing. So, the XACML request and response syntax should allow the use of URIs to represent the actual resource. Not simply "the thing whose URI is ...", but "this-URI".
The XACML 3.0 request syntax is built entirely on attributes. One low-impact approach would be to add a new AttributeId to convey the URI of the object. However, this syntax does not reflect the true intent. The URI is not an attribute of anything--it is the thing, insofar as it stands in for the real-world thing.
A better approach might be to borrow from the RDF/XML syntax. The following samples illustrate these two approaches.
Using a distinguished AttributeId:
<Attributes Category="...resource"> <Attribute AttributeId="...URI" DataType="...anyURI">http://example.org/Document999</Attribute> </Attributes>
Using RDF/XML syntax:
RDF for attribute metadata
Because of the extensibility of RDF, it can easily be used to connect other components of a XACML system to the attribute vocabulary. It can be used to inform the PIP of where to obtain values for each attribute.
:AttributeA :system "System X" .
It could be used to specify that one attribute is a key value for looking up another attribute.
:AttributeA :key :AttributeB .
There might be several possible sources for an attribute, and they should be consulted in a particular order; or, a bag of attribute values should be collected from all possible sources. Any important relationships among attributes, and between attributes and the environment, can be easily expressed in RDF. These can then be used to direct the runtime behavior of the XACML system.
Another possibility is to use entailment to augment the request context. If my ontology has a subclass of Document called SpecialDocument, and a request contains type="SpecialDocument", then by entailment I can add type="Document" to the request context, by virtue of the fact that my ontology definition says:
:SpecialDocument rdfs:subClassOf :Document .
This could be useful if I don't want to write policies targeted at SpecialDocuments, but my PIP might need to consult different sources for attributes of SpecialDocument. We don't want to force the PEP to include type="Document" and type="SpecialDocument". So the first thing the PIP does is to discover all the additional types entailed from the initial request context.
Alternatively, a PIP could be implemented as one or more SPARQL endpoints.
Opportunities for standardization
The TC should consider work items aimed at producing normative RDF/OWL definitions of the core XACML vocabulary, as well as standards or guidelines to foster interoperability of RDF interpretations of XACML.