Hi David, I do not understand your work items: (a) should the initial request respect the XACML request form (e.g. in JSON format) or is a simpler form still acceptable? (b) should the response be shrunk down to a boolean true (permit) / false (deny)? for the sake of simplicity or should we try to respect the richness of a XACML decision (status, decision, obligation / advice)? What does it mean to: (a) not respect the XACML request form ? (b) not respect the richness of a XACML decision ? I am not aware of any problems with either the XACML request or the XACML decision, so why is the premise of this work based on implying there is something wrong w XACML that needs to be fixed? If there is something that needs fixing, please specify what it is. Since we already agreed (as has been established at least since XACML 2.0 was published) that the form on the wire does not need to be XML, and that it could be JSON, for example, is this still not good enough to meet some objective? If that is the case, what is the target objective? Thanks, Rich On 6/6/2011 3:40 PM, David Brossard wrote: BANLkTikUhJa7yk8V9GPOjZfhVF1-S=
CHKg@mail.gmail.com type= cite >Hi all, Apologies for missing last week's call. I was travelling back from the US. I would now like to proceed with the formal definition of a PEP - PDP simplified interface. After quite a bit of discussion on the list, I would like to clarify a few points: (a) this does not address the PAP side of things - in other words the management (b) this is about developing a simple interface to let developers consume AuthZ in a more user-friendly way (c) we have concluded the XACML spec does not mean we have to use XACML in its XML form Where there is still room for work / definition is: (a) should the initial request respect the XACML request form (e.g. in JSON format) or is a simpler form still acceptable? (b) should the response be shrunk down to a boolean true (permit) / false (deny)? for the sake of simplicity or should we try to respect the richness of a XACML decision (status, decision, obligation / advice)? The end-product should be sthg we could expect in developer frameworks / languages in the form of a drag 'n drop type component. I am thinking of such frameworks / languages as Google Apps or Google Web Toolkit, .Net, J2EE, Ruby... On Wed, May 25, 2011 at 3:22 PM, PRATEEK MISHRA <
prateek.mishra@oracle.com > wrote: David, Anil - I would like to bring your attention to the OpenAz project which focuses on the creation of XACML PEP's. Currently, the project includes Java and C++ bindings and we would welcome other bindings to languages such as Ruby and Python. Rich Levinson and Hal Lockhart have previously published materials to this TC describing the APIs and other essential pragmatic materials (attribute manifest) needed to easily create XACML PEPs in a variety of contexts. IMHO, creating yet another protocol for PEP <--> PDP interaction is helpful but not very important step in making XACML-style PEP available in a variety of contexts. The PEP <--> PDP interaction usually requires efficiency and is implemented in a variety of different proprietary ways. There is nothing in the XACML specification that suggests that it has to be drawn from the standard. In our experience with real-world, enterprise class business applications and their authorization requirements, we find that creating a flexible model for embedding PEPs and obtaining attributes in a variety of contexts to be much more important. Some of the issues encounter include: + Training of architects and developers so that they understand the XACML PEP interaction model. + How can PEPs be added to specific points in applications, middleware, gateways and devices? + How can we efficiently and securely transfer identity attributes from native run-time system (e.g., Java principals) to the authorization system? + How can we expose business objects to the authorization system? + How can we communicate information about attributes required in policies to other repositories, including the application at run-time? Thanks, prateek OpenAz project link -
http://www.openliberty.org/wiki/index.php/Main_Page#OpenAz 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 <
Anil.Saldhana@redhat.com > 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 <
Anil.Saldhana@redhat.com > 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 <
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 -- 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