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