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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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:kirschheiko@googlemail.com]
Sent: Wednesday, February 17, 2010 09:25
To: xacml-comment@lists.oasis-open.org
Cc: michael.hoche@eads.com
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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]