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
- From: "Tyson, Paul H" <PTyson@bellhelicopter.textron.com>
- To: "Heiko Kirsch" <kirschheiko@googlemail.com>,<xacml-comment@lists.oasis-open.org>
- Date: Thu, 18 Feb 2010 13:21:32 -0600
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
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]