Re: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working dra

Subject: Re: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded

Hi Ray, all,

Here are my initial comments / revisions.

The intro in section 1. Introduction has missing references
Section 1.4 "Use Cases" doesn't really contain use cases but rather drivers for the profile i.e. why would one want to go for a RESTful authZ service.
Section 1.4.2 mentions the CSA's work on security as a service and in particular their view of AZaaS. One thing to keep in mind is that authentication is often a one-off process and is valid for the duration of a user session whereas authorization happens all the time. This means that an AuthN service would see less load than an AuthZ service. I worry that the frequency of use of an AuthZ service might prescribe the service form factor for authorization. In any case, this is worth mentioning to people interested in AuthZ as a service. This is also why we see a greater number of authN services than we do authorization services IMHO.

Section 1.4.3:

Couple typos.

network-addressable (missing hyphen)
is often built... --> I would say can be built. I am not sure how prevalent RESTful services are vs. other WS or APIs.
In the second paragraph: REpresentational State Transfer (REST) is a system...(the a is missing in the text)
same line: ...that governs... (missing s)
In bullet 4. "Layered system": ...with which it is interacting... (instead of they are)

Section 1.4.4 RESTful Authorization as a Service

The title of the paragraph is a bit contradictory with the definition inside: the use of XACML in a RESTful architecture. It is one thing to have an AuthZ service delivered as a RESTful service, it is another concern to deliver AuthZ that fits a RESTful architecture (where the apps being protected are what is restful, not the AuthZ). Obviously the focus of this profile is to deliver AuthZ as a RESTful service.

Section 2.1: the layout seems wrong.

Sections 2.3.1 to 2.3.3: perhaps we should indicate that the status codes do not reflect the authorization itself but rather just the state of the service / transport of the service.
Section 2.3.2: the XACML request's format is not specified here. That's where I would like to hook into the profile I had initially started (the JSON over HTTP PDP interface). That profile would define what the representation of a XACML request and response is in JSON.

Section 2.3.3: wrong verb use.
Since the XACML specification mandates that PolicyId and PolicySetId be (instead of are)
Also perhaps add a link to the XACML spec where it specifies id uniqueness?

Section 2.3.4
In addition to the cases you list, Ray, I would add: attempt to put a policy(set) with a broken policy reference leads to 409 too. In other words, you have to push the referenced policies first then push the policies that reference them next.
Also, how do you want to handle multiple policies? How are they combined? What if you have a policy and referenced policies? Do you want to mark a policy as a main entry point? This is undefined in the XACML standard I believe.

I hope this helps. Cheers,
David.

On Tue, Apr 24, 2012 at 1:02 PM, Remon Sinnema <remon.sinnema@emc.com> wrote:

Submitter's message
All,

First full draft defining RESTful services for XACML. Comments are very much appreciated.

Thanks,
Ray
-- Mr. Remon Sinnema

Document Name: REST Profile of XACML v3.0 Version 1.0, working draft 02

No description provided.
Download Latest Revision
Public Download Link

Submitter: Mr. Remon Sinnema
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2012-04-24 04:02:21

--
David Brossard, M.Eng, SCEA, CSTP
VP Product Marketing & Customer Relations
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics

xacml message