Dear all,
To summarize what's been said:
(a) naming the interface "REST" is misleading - let's drop the name.
(b) there is a need for a standard interface (transport / communication) and not just the XACML request/response.
(c) interface standardization could be done in a profile - it's easier than touching the XACML core and it keeps concerns clearly separated.
Today we have the SAML for XACML profile. Moving to a SOAP-only interface would be a great step forward.
Independently of the above, would it be interesting to design / standardize an easy-to-consume interface, something easier than what we have today? Something more in the likes of a GET request with simple GET parameters?
Is there a common place where we could gather requirements and ideas or is this email thread the way to go forward?
I will be a Gluecon 2011 tomorrow and Thursday. I will try to gather requirements from the developer community.
Cheers,
David.
On Tue, May 24, 2011 at 7:48 AM, Anil Saldhana <> wrote:
Craig,
if you want to take the wsdl standardization task, I will support
you.
Regards,
Anil
On 05/20/2011 04:55 PM, Craig R Forster wrote:
Hi all,
I agree that calling such an API a "REST" API is a misnomer.
>> So what is of interest is merely the
HTTP protocol indeed and binding the XACML request / response
to GET or POST verbs along with a potential mapping into
simple HTTP request parameters or a JSON payload.
If the payload is an XACML request in it's currently-defined XML
form, then I don't see any benefit to using HTTP POST rather
than SOAP. SOAP has better tooling, and only adds two elements
as a wrapper in it's minimal form ( <soap:Envelope> and
<soap:Body>). For there to be any benefit I think the
payload would have to be JSON, in which case we'd have to define
a canonical way to represent XACML requests and responses in
JSON form.
Mapping attributes in an XACML request to individual HTTP GET
parameters seems cumbersome. I think the better approach is to
define an entire request as a JSON object and send that via
whatever HTTP verb is most applicable.
However, I think it'd be more prudent to first define a
canonical WSDL for an XACML PDP web service. The TC has been
reluctant to do this in the past, for whatever reason, and while
it doesn't overlap with a JSON over HTTP protocol I think that
it's worth standardizing first.
Regards,
Craig
David
Brossard ---05/20/2011 10:27:11 AM---Hi, That's true... This
might be more about exposing the PDP with the lowest
From:
David Brossard
<>
To:
Cc:
Date:
05/20/2011 10:27 AM
Subject:
Re: [xacml] PDP REST Interface - proposal
Hi,
That's true... This might be more about exposing the PDP with
the lowest possible barrier to entry - making an authorization
request as simple as can be.
Since the PDP is stateless by design, a pure REST approach is
therefore a mismatch since REST is aimed at providing support
for stateful web services.
So what is of interest is merely the HTTP protocol indeed and
binding the XACML request / response to GET or POST verbs along
with a potential mapping into simple HTTP request parameters or
a JSON payload.
Cheers,
David.
On Fri, May 20, 2011 at 5:04 PM, <> wrote:
David,
From: David Brossard [mailto:]
Sent: Friday, May 20, 2011 4:20 PM
To: xacml
Subject: [xacml] PDP REST Interface - proposal
>> 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. <<
I don't see any "resources" in your proposal. So
I guess you're just talking about an HTTP interface, not REST.
>> 2 possible methods: GET and POST
* GET
o Input: Send in a URL e.g. http://foo.bar/AuthZ/?a=value&b=value2&c=value3
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
attribute
* 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 <<
I guess you could model Decisions as HTTP status
codes:
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. <<
A lot of web services these days support both XML and JSON.
The former is better for consumption by server code, while the
latter is easier to consume by a JavaScript client.
>> 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?
>> 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? <<
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.
Thanks,
Ray
--
David Brossard, M.Eng, SCEA, CSTP
Solutions Architect
+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
