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

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

Hi Ray, see comments below.

> -----Original Message-----
> From: remon.sinnema@emc.com [mailto:remon.sinnema@emc.com]
> Sent: Monday, 05 March, 2012 05:12
> To: Tyson, Paul H
> Cc: xacml@lists.oasis-open.org
> Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0
> uploaded
> 
> 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.
> 
[pht] Yes, but I don't see anything as good as using these syntactic elements, and adding some stricter requirements. Any mapping to local system artifacts should happen locally. If you let any values of PolicyId or PolicySetId into the cloud that aren't unique, canonical URIs you are asking for trouble.
> 
> > 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.

[pht] But that doesn't move us very far along toward enabling XACML to be fully and transparently part of the WWW. I'm suggesting we take this opportunity to consider some simple changes that would improve the viability of XACML in a cloud AaaS.

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

[pht] One way to classify use cases is by the degree of independence of policy authors from the subjects and resources about which they write policies. In a typical enterprise access control scenario, the rule-writers work for the same organization that owns the resources and employs most or all of the subjects (and the relationships with non-employee subjects are tightly controlled). I don't see much motivation for moving this scenario to the cloud for AaaS. However, in other scenarios the rule-makers are completely independent of the resource owners (or creators, or publishers), and have little or no organizational control over the subjects. Export control law is one such example; in fact, any policy derived from government laws falls into this category. (Intellectual property policies fall somewhere in between, as do company-specific exceptions to export control laws.) My point is that cloud AaaS becomes more attractive as the rule-makers are farther removed from the subjects and resources they regulate. And it is correspondingly more important to treat the XACML subjects and resources as REST resources in their own right. This not only facilitates RESTful exchange of information about them, but provides a means to assure the rule-makers that authorization decisions are being made with correct information. SAML provides one such mechanism for this, and perhaps could be recommended for this purpose by the XACML REST profile. (However we are in for major terminological confusion if we try to treat SAML:Subject as a subset of REST:Resource, on top of considering REST:Resource to be a superset of the union of XACML:Subject, XACML:Action, XACML:Resource, and XACML:Environment.)
 
Regards,
--Paul