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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0 uploaded


Here are some comments not so much on AaaS, but on the key REST concept of "resources" as I think they pertain to a XACML ecosystem. I don't think a XACML AaaS will work until the underlying REST principles are applied to XACML in a standardized manner.

Consider the REST idea that "everything is a resource", and that all resources can be identified (and possibly accessed) by a URI. XACML falls short on two counts here:

First, XACML policies themselves must be viewed as REST resources, but are currently not required to be identified by URI. Furthermore there is no formal distinction between the abstract notion of a XACML "policy" and its concrete representation as a "policy document". This could be fixed in the REST profile by requiring PolicyId and PolicySetId values to be absolute, resolvable URIs (or IRIs), and by specifying that these values are to be interpreted as the unique, canonical identifier of the abstract policy. The mechanism adopted in the OWL2 specification seems to have solved this problem neatly, and could be adopted for the REST XACML profile. See http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontologies, particularly sections 3.1, 3.2, 3.3, and 3.4.

Secondly, a XACML policy can be understood (in a REST context) as a set of rules for mediating the hyperlinked relationships amongst REST resources. XACML divides the universe of REST resources into XACML Resources, Subjects, Actions, and Environment, but again none of these are required or expected to be identifiable by URI in a XACML ecosystem. (The XACML categories in 3.0 are extensible beyond these built-in categories. And since non-web things such as buildings, people, and manufactured products can be represented with URIs, it is conceptually accurate and useful to understand a XACML policy in this way with respect to REST.) The mediation performed by evaluating a request against a policy can result in any of several "state transfer" alterations, including: complete denial, transparent permit, censored permit, and permit (or deny) with obligations affecting the state of yet another (REST) resource.

I've previously noted the inability to directly name (by URI) a Resource, Subject, or Action in a XACML request context. (http://wiki.oasis-open.org/xacml/XACMLandRDF.) I would strongly urge adding syntax for this, if not in the core spec then at least in the REST profile. A corresponding mechanism to test for "is"-ness would be needed in the policy language. Two features are needed for this: a syntactical construct to refer to the thing that *is* the subject, resource, or action in the request context; and a (REST) resource identity predicate. The latter requirement could be met by adopting owl:sameAs as a function identifier taking two anyURI arguments. That would allow one to say "if the subject owl:sameAs <http://old-testament.example.com/people/Eve> and the resource owl:sameAs <http://garden-of-eden.example.org/TreeOfKnowledge> then Deny". (This example also shows that the fall of Man was due to defective access control, which might help make a business case for XACML.)

Furthermore I think there is room for improvement in defining the RESTful representation of resources when they are XACML Resources and Subjects. We have a concrete representation of a XACML Request, which contains attributes of specific subjects, resources, and actions. And we have a generalized concept of "request context", which is a collection of bags of attribute values distinguished by category, datatype, id, and issuer. But we don't have anything that directly defines a RESTful transaction between a client and a server for a specifically XACML representation of a particular Resource, Subject, or Action. I'm not sure what this would look like, but one purpose it would serve is to formalize the communication between a PDP and PIP: the PDP says "give me a XACML representation of subject X" and the PIP responds with its representation of subject X. This would probably be a collection of <xacml:Attribute> elements, but we currently don't have any wrapper element to define an independent syntactic representation of a particular XACML Resource or Subject. I don't know if this warrants a new media type as well, but I'm inclined to think it does.

Regards,
--Paul


> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of remon.sinnema@emc.com
> Sent: Wednesday, 29 February, 2012 02:35
> To: xacml@lists.oasis-open.org
> Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0
> uploaded
> 
> All,
> 
> We didn't have time to discuss this on the last call so I'd like to ask
> you for feedback on the use cases identified in the uploaded document.
> It basically focuses on Authorization as a Service, since this is the
> most demanding use case and all the other use cases can be solved with
> the same solution.
> 
> Thanks,
> Ray
> 
> 
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Remon Sinnema
> Sent: Tuesday, February 14, 2012 5:51 PM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0
> uploaded
> 
> Submitter's message
> Use cases to be covered by the profile.
> -- Mr. Remon Sinnema
> [...]
> 
> http://www.oasis-
> open.org/committees/document.php?document_id=45154&wg_abbrev=xacml
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org



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