OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] PDP REST Interface - proposal


Hi All,

My initial 2 cents on this is that translating the XACML Request/Response elements,
w all their descendants to JSON and sending it over HTTP would be enough to prevent
XACML being labeled as a "SOAP-based" interface, just because we happen to have one
in the XACML/SAML profile. i.e. I would support using a XACML JSON/HTTP profile as a
starting point.

Also, as I am sure most people are aware, the Request (section 5.42) and Response
(section 5.47) context elements, are represented as XML documents in spec, however,
there is no requirement that these context representations ever exist as XML, as
long as whatever representation is used (ex. JSON) will produce the same results.

Therefore from the specifications point of view, a JSON/HTTP representation is just
as good as an XML representation, or,  a Java RMI representation. This is also mentioned
in section 3.2 (line 496 in wd19 (however, not JSON, which we might consider adding)).

    Thanks,
    Rich


On 5/20/2011 5:55 PM, Craig R Forster wrote:
OFF6508E36.DBA9022E-ON86257896.007602BC-86257896.00786E3C@us.ibm.com" type="cite">

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


Inactive
          hide details for David Brossard ---05/20/2011 10:27:11
          AM---Hi, That's true... This might be more about exposing the
          PDavid 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 <david.brossard@axiomatics.com>

To:

remon.sinnema@emc.com

Cc:

xacml@lists.oasis-open.org

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, <remon.sinnema@emc.com> wrote:
    David,


    From: David Brossard [mailto:
    david.brossard@axiomatics.com]
    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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]