[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] PDP REST Interface - proposal
From: David Brossard [mailto:firstname.lastname@example.org]
Sent: Friday, May 20, 2011 4:20 PM
Subject: [xacml] PDP REST Interface - proposal
I don't see any "resources" in your proposal. So I guess you're just talking about an HTTP interface, not REST.
>> Following the call yesterday, I would like to kick start some discussions around the possibility around designing a standard REST interface for a PDP. The idea would be to have a PEP-PDP interaction using REST. <<
o Input: Send in a URL e.g. http://foo.bar/AuthZ/?a=value&b=value2&c=value3
>> 2 possible methods: GET and POST
o Output: the decision (the whole XACML decision? simply the decision string e.g. "Permit"? an HTTP status code?)
o Pros: extremely easy to consume
o Cons: the request sent / response received are not valid XACML requests / responses.
* This means a layer on the PDP side (in the REST wrapping) needs to map from a HTTP GET parameter to a XACML attributeI guess you could model Decisions as HTTP status codes:
* In addition, if the response is merely a status code or a String, it breaks the XACML standard in the sense that obligations / advice would be lost <<
Permit - 200 OK
Deny - 403 Forbidden
NotApplicable - 404 Not Found
Indeterminate - 500 Internal Server Error
The obligations/ advice could then be in the response body.
As for the mapping from HTTP parameters to XACML attributes, I don't think this is a big deal. I'm assuming most implementations don't use the XML format of the spec internally, so there has to be some sort of mapping anyway. This new mapping seems like a fairly easy addition.
>> * POST
o Input: the entire XACML request in its XML form
o Output: the entire XACML response in its XML form
o Pros: complies with the XACML standard
o Cons: what is the benefit other than performance? It doesn't make adoption easier <<
Since an authorization request is idempotent, I would propose PUT instead.
>> * POST using JSON
o Input: the JSON representation of a XACML request
o Output: the JSON representation of a XACML response
o Pros: all the richness of XACML. The format is JSON which developers seems to prefer.
o Cons: perhaps a bit too cumbersome. <<
>> What are your thoughts? <<
Sounds interesting. Do you have any (potential) customers that expressed interest in this? What are the use cases you are trying to solve with this proposal that you can't with the current spec?
You won't lose any richness in the PUT variant. I'm not sure about GET either, that depends on the mapping of XACML attributes to HTTP parameters.
>> Do you think any standardization effort / profile definition effort should be driven by a developer community willing to use authorization and which would want to sacrifice the richness of XACML for the sake of simplicity? <<