Re: [xacml] PDP REST Interface - proposal
Hi David,
from queries from the field, I have primarily seen demand for SOAP
based PDP services at this time. Hence my support for standardizing
the wsdl.
The challenge has been easy authorship of the xacml policies.
In recent times, I have seen an uptake on xacml related queries
coming to my blog (that has xacml entries). So I can tell that
people are dealing with xacml around the world compared to what was
2 years ago.
Regards,
Anil
On 05/24/2011 05:38 PM, David Brossard wrote:
Hi Anil,
Sorry, I did not mean to give you heartburn with the words "soap
only". I do agree with your point. I wrongly applied the shortcut
SOAP == WSDL which of course is not true.
Our new goal should be to define a standard interface using WSDL,
possibly WSDL 2.0.
That interface could then be used for SOAP-based communication,
HTTP/GET-based communication or even JSON-based at the
implementation's discretion. Those details could potentially be
standardized w/in the very same profile.
Regardless of communication / transport protocol and interface
definition, should we assume that what is being carried is always
the XACML request as defined in the XACML specification? If so, it
effectively discards JSON (to go to your point re. JACML :p) and a
simple PEP-PDP HTTP/GET interaction where GET parameters would be
used as simple key-value pairs.
And again back to my initial thoughts and the reasons behind this
conversation, we should make that interface as easy and simple as
can be (in addition to standard) to further facilitate XACML
adoption and help developers quickly develop PEPs to consume XACML
authorizations.
So do we agree we should define a WSDL 2.0 interface? How widely
adopted is WSDL 2.0 vs. WSDL 1.1?
Cheers,
David.
On Tue, May 24, 2011 at 5:12 PM, Anil
Saldhana <>
wrote:
Hi David,
please don't portray xacml to be a SOAP intensive tech. I
have heartburn with the words "soap only". We need a
standardized wsdl such that the soap side of the world can
be happy. But interfaces to the PDP does not have to be SOAP
alone. I will take in any transport that can move my xml
payload (xacml request/response) from one point to another.
SOAP (with saml/xacml payloads), REST (xml over http
architecture) and plain xml over http are all possibilities.
XACML is a XML language that defines access control rules.
If we want to use json as one of the authoring means, we
have to rename it to jacml. ;)
We are just defining various mechanisms to transport the xml
(xacml) payload. Whether it is http or soap transport
mechanism, that does not take away the primary goal of xacml
- to define access control constructs.
My thoughts only.
Regards,
Anil
On 05/24/2011 04:20 PM, David Brossard wrote:
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