← Prev in month
← Prev in thread
Next in thread →
Next in month →
Re: [xacml] Re: Towards the creation of XACML PEPs (WAS Re: [xacml]PDP REST Interface - proposal)
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:
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 <>
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 <>
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
--
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
← Prev in month
← Prev in thread
Next in thread →
Next in month →