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

[<remon.sinnema@emc.com>]

David,


From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of David Brossard
Sent: Tuesday, April 24, 2012 3:34 PM
To: Sinnema, Remon
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded

> The intro in section 1. Introduction has missing references

Which ones? Where?


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

So you'd rather see it named "Rationale", or something like that?


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

Sure.


> I worry that the frequency of use of an AuthZ service might prescribe the service form factor for authorization. <<

I don't understand what that means.


> In any case, this is worth mentioning to people interested in AuthZ as a service.

OK, I'll add it to the text.


> This is also why we see a greater number of authN services than we do authorization services IMHO.

Also, authZ requires authN.



> Couple typos.

Thanks for catching those.


> is often built... --> I would say can be built. I am not sure how prevalent RESTful services are vs. other WS or APIs.

They are becoming ever more popular (especially when you count all the HTTP-based services that claim to be RESTful but don't implement all the constraints).


> same line: ...that governs... (missing s)

The constrains govern, not the system.


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

I'm not sure I understand your point.

The main use case that the profile intends to make possible is AZaaS. Given the expected load, as you mentioned earlier, that will put on a (cluster of) server(s), scalability is of the utmost importance. The REST constraints make that a system scales well, so REST is a natural choice for AZaas.


> Section 2.1: the layout seems wrong.

In what way?


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

Good point.


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

I would think that that is the job of the Media Types profile. We can certainly pull it out of there and put it in a different profile, but whatever profile defines the JSON format for requests and responses should also define the JSON format for policies and policy sets. So that doesn't seem to match with the "PDP" part of your profile's title.


> Also perhaps add a link to the XACML spec where it specifies id uniqueness?

Yes. That would be 9.2.5.


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

Good one.


>> 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 think you're right that it is undefined. I don't think that it is the right place to define it here. This profile is just to make clear how to implement what the core spec defines in a RESTful manner, not to augment the core spec.


> I hope this helps. 

It does, thanks.


Thanks,
Ray