RE: [xacml-comment] Request for Change XACML 3.0

I'm glad to see a semantic approach to the XACML context 
handler.  However, I'm not convinced that the XACML spec should define an 
Ontology Decision Point.  The context handler and PIP already allow any 
type of semantic implementation desired.  I think there are many 
opportunities to use ontology-aware components here, from simple RDF entailment 
to full reasoners.  See http://wiki.oasis-open.org/xacml/XACMLandRDF for 
a few notes on the subject.

 

I suggest that the main obstacle 
to semantic-enabled XACML is the inability to test the ontology model 
using XACML rules.

 

The specific use case discussed in the proposal is not a good 
example for ontology processing, because it does not define any classes, 
nor does it make use of class or property hierarchies.  It is simply an 
enumeration put into OWL, using the transitive property, 
"more_confidential_than", to order the elements.  If the ontology were 
fleshed out, the class of TopSecret things would be disjoint from the class of 
Secret things, and also from the classes of Confidential and Restricted 
things.  Perhaps this is actually the intent of the 
ontology.  However, we usually consider all TopSecret things to 
also be Secret, etc., because people with TopSecret clearance can also 
see Secret, Restricted, and Confidential things.  Indeed, the rules in 
the use case have this effect.

 

There are several different ways to improve the 
semantics.  The easiest way might be to define a hierarchy of RDF classes, 
like:

 

   myOnt:TopSecret rdf:subClassOf 
myOnt:Secret

    myOnt:Secret rdf:subClassOf 
myOnt:Confidential

    myOnt:Confidential rdf:subClassOf 
myOnt:Restricted

 

(for completeness you could add:

    myOnt:Restricted rdf:subClassOf 
xacml:Resource

    xacml:Resource rdf:subClassOf 
rdfs:Resource)

 

Next, define classes for subject clearance levels.  
In this case it is not necessary to put them in a hierarchy, but 
conceptually it makes sense.

 

    myOnt:TopSecretClearance rdf:subClassOf 
myOnt:SecretClearance

    myOnt:SecretClearance rdf:subClassOf 
myOnt:ConfidentialClearance

    myOnt:ConfidentialClearance rdf:subClassOf 
myOnt:RestrictedClearance

 (myOnt:RestrictedClearance rdf:subClassOf 
xacml:Subject

    xacml:Subject rdf:subClassOf 
rdfs:Resource)

 

Then the rules you want are like:

    - ConfidentialClearance subjects can see Confidential and 
Restricted resources, but no others

    - SecretClearance subjects can see Secret, Confidential, and 
Restricted resources, but no others

    - etc.

 

In general, each clearance class of subject can see the 
corresponding security class of resources, but cannot see any resource whose 
type is a subclass of the highest allowed class.  The SPARQL query for 
these 2 conditions would look like:

 

# must be YES when :thisSubject rdf:type 
myOnt:SecretClearance

ASK {:thisResource rdf:type myOnt:Secret 
.}

 

# must be NO for same subject

ASK {:thisResource rdf:type ?t .

            
?t rdf:subClassOf myOnt:Secret 
.}

 

You can write XACML rules equivalent to SPARQL 
clauses like ":thisResource rdf:type myOnt:Secret", but not for "?t 
rdf:subClassOf myOnt:Secret".  Without that capability, you would have to 
write XACML rules to test for each type.

 

This looks like a complicated approach, but it minimizes the 
coupling between your rules and your enterprise ontology.  If later you add 
a new classification, "TopMostSecret" as a subclass of "TopSecret", none of your 
existing rules are affected.  You just have to add a new rule for the new 
classification.

 

In order to make this sort of thing work, your context 
handler would have to convert the request into an RDF model, read the rdfs file 
containing the class definitions, and entail all the additional triples 
regarding sub-types.  For example, if the original request context has 
rdf:type="Secret", the context handler would supply rdf:type="Confidential" and 
rdf:type="Restricted" by entailment.  The Jena library provides this 
capability by simply instantiating an RDFS inference model.

 

As this example illustrates, XACML could enable more semantic 
processing by providing a way to write rules to test the ontology model.  
In this case we just want to test a subclass hierarchy, but in other cases you 
might want to test for disjointness, sameness, or other conditions among 
classes.

 

Regards,

--Paul

 

 

  

  
  From: Heiko Kirsch 
  [mailto:] 
Sent: Wednesday, February 17, 
  2010 09:25
To: 
Cc: 
  
Subject: [xacml-comment] Request for Change 
  XACML 3.0

  

  
Dear Sir or Madame,

  

  
the appendix to this Mail is introducing 
  an enhancement for XACML 3.0

  
We suggest establishing an Ontology 
  Decision Point in the XACML-model to use ontologys for an authorization 
  decision.

  

  
Sincerely yours

  
Heiko 
Kirsch