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

[<remon.sinnema@emc.com>]

Paul,


> -----Original Message-----
> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Sent: Thursday, March 01, 2012 6:21 PM
> To: Sinnema, Remon; xacml@lists.oasis-open.org
> 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.

I think it should be possible to wrap the current XACML items in a RESTful manner without changing the core spec.


> 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 REST profile can define a way to associate XACML policies with URIs, without requiring PolicyId and PolicySetId to be resolvable URIs.


> 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.

Thanks for the pointer, I will take a look at it.


> 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.

While I don't necessarily disagree with the above, I don't think we need to solve this issue for the identified use case of Authorization-as-a-Service. To use such a service, we need to be able to create/read/update/delete policies, and we need to be able to get authorization decisions based on those policies. The former needs only to refer to policies, the latter to the request and response contexts. I don't see a need to refer to, say, a subject as a REST resource.

But first let's get consensus on the use cases that the profile must support.


Thanks,
Ray