Hi Ray, > -----Original Message----- > From:
remon.sinnema@emc.com [ mailto:
remon.sinnema@emc.com ] > Sent: Thursday, 01 December, 2011 03:33 > To: Tyson, Paul H > Cc:
xacml@lists.oasis-open.org > Subject: XACML & RDF > > Paul, > > About
http://wiki.oasis-open.org/xacml/XACMLandRDF > > > "XACML and RDF" > > "2. Add provisions in the request/response syntax to identify > resources, subjects, and actions by URI alone." > > According to the 3.0 core spec (lines 2418-2419), attributes are > identified by all of category, attributeId, data type, and issuer (if > present). I'm assuming there were good reasons to include category et > al? In practice, I don't think I've seen any attributeId reused across > categories. Is anyone actually doing that? Quadruple-keyed attributes is a different issue than what I was talking about. I was suggesting that we should provide a means to identify subjects and resources by *name* (URI) instead of by attribute values. So I could say "the resource is <
http://example.com/docs/Document1 >" instead of "I'm thinking of a resource, and the URI of the resource is '
http://example.com/docs/Document1 '". Referring to things by their URI is a fundamental idiom of the semantic web. We don't say "the document whose URI is '
http://example.com/docs/Document1 ' was created by a person whose name is 'John Doe'. We say (in turtle): '<
http://example.com/docs/Document1 > dc:creator "John Doe".'. (Well, actually, it's more complicated than that because of the way Dublin Core terms are defined.) The point is that the document URI is the grammatical subject in this statement. In fact, it's cumbersome to say in RDF, "the document whose URI is ...". You would have to make up a property, like 'hasURI' or something, but then you have converted essence to attribute and lost some of your expressive capability. That is one option for doing it in XACML, but I'm suggesting we adopt a nicer idiom. > > > "3. Extend the policy language to test ontological conditions such as > subclass membership and class relations." > > What extensions do you think are necessary to support such features? I haven't thought it all out. For writing the tests in a Condition or Match element, we can use rdf:type and rdfs:subClassOf as attribute values. However, this presumes some knowledge of an ontology that defines the classes that these predicates refer to. So we need some sort of ontology import mechanism, perhaps by naming the required ontologies (by URI) at the top level of Policy or PolicySet. These ontologies then would be available in the request context. > > > "Attributes/properties of what?" > > The Document example rule matches any document, but in practice one > would often want to grant access to a limited set of documents. I think > we need to some semantic definitions on attribute *values* to handle > this. That seems to be the case for hierarchical actions as well. I'm not quite sure what you mean here. There is a difference between granting access to a class of documents versus granting access to any particular document, and there should be different rules in these cases. XACML makes it easy to confound these cases because policy writers often think in terms of classes of resources and subjects. But requests are for individual resources: a *particular* marketing document, not *all* marketing documents. The rule might say "if the subject is in the marketing department, and the resource is a marketing document, then permit". But the request does not ask "can a person in the marketing department see all marketing documents?", nor could this policy respond to such a request (except by iterating over the population of marketing documents). To respond directly to a request like this, the rule would have to say "if the subject is in the marketing department, and the resource is *the class consisting of all marketing documents*, then permit". But XACML is usually implemented in order to make fine-grained access control decisions that cannot be handled easily by ACL or RBAC. The Target and Condition elements of XACML can be thought of as defining codependent classes of subjects, resources, and actions. If the request represents a set comprising at most one each *individual* subject, resource, and action that are in those classes, the rule is effective. > > Another example where that would be helpful is with hierarchical roles. > A policy may grant access to 'employee', but the request may specify > 'manager' as the value for the role-id attribute. The ontology should > be able to define that 'manager' implies 'employee'. The RBAC profile > allows us to specify such a role hierarchy, but not very elegantly > IMHO, since the permission PolicySets "must be stored in the policy > repository in such a way that they can never be used as the initial > policy for an XACML PDP" (lines 160-161). Defining the role hierarchy > as an ontology, and specifying some machinery in the context handler to > process ontologies could improve the RBAC profile. I haven't analyzed this. I think RBAC is a bit ontologically muddled to start with, so I'm not sure it's profitable to try to build much on top of it. > > > "RDF for attribute metadata" > > "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." > > According to Figure 1 of the core 3.0 spec (lines 475-478), the PIP is > asked for attribute values *after* the PDP decides it needs them. What > in the Document/SpecialDocument example would make the PDP request > attribute values from the PIP? Or did you mean the context handler? Yes, the context handler would have to take on the semantic duties of entailment and reasoning. Regards, --Paul