I think a related, and IMO more important question is whether the TC should consider defining a REST API for creating, reading, updating, and deleting XACML policies for a PDP. I think having such an API is a de facto
standard expectation for modern web applications in which even the interactions between a frontend GUI with the backend service is expected to take place over a well-defined REST API with CRUD operations, let alone if the PDP is to provide some form of a SaaS
access control service in which a user can add/remove/update/delete policies and later query those policies using XACML REST+JSON request/responses.
I think defining this piece will be a much more important priority in making XACML available to a wider audience of developers/applications who work with the REST/JSON based stacks.
Now, although defining such an API is orthogonal to having a JSON encoding for XACML policies (since the policy can still be encoded in XML and wrapped inside a JSON field perhaps with something like base64 encoding),
it will definitely be more desirable to be able to encode the policy in JSON in such an API.
Regards,
Mohammad
From: <xacml@lists.oasis-open.org> on behalf of Martin Smith <bfc.mclean@gmail.com>
Date: Friday, October 26, 2018 at 8:50 AM
To: David Brossard <david.brossard@axiomatics.com>
Cc: rich levinson <rich.levinson@oracle.com>, XACML TC <xacml@lists.oasis-open.org>
Subject: Re: [xacml] json policy profile?
David, all-- I definitely agree that it would be great to have a more "user-friendly" policy language. I think a common language would be better than relying on different tool makes to make the XML grammar user-friendly in their own separate
ways. And by "better" I mean better for vendors as well as users, since a more approachable policy language would increase general interest and uptake of the XACML approach to ABAC.
However, I'd further suggest that the ideal policy language would not be aimed at programmers, but at policy analysts. So although ALFA is a big improvement over XML, it's still aimed at IT people and not policy people, and one of the obstacles
to ABAC adoption (IMHO) is that it keeps being treated as "an IT thing."
Hi Rich, all,
This is a recurring question. It's been asked on
Stackoverflow. If you remember, there was a lab in Ireland that had worked on a JSON format. Bernard Butler wrote on this mailing list about it. See
here. In the Stackoverflow question I linked to above, Cyril Dangerville mentions that they used a direct XML-to-JSON mapping to achieve XACML policies in JSON:
there are well-known conventions to convert XML to JSON (with limitations), mostly used by REST API frameworks. So if you know the XML format, the convention tells you the JSON format. For example, Apache CXF used to support two conventions:
Badgerfish and the mapped convention. Badgerfish is no longer maintained in CXF therefore the mapped convention is preferred now.
The mapped convention is what AuthzForce Server - another ABAC/XACML implementation - uses for the RESTful PAP (Policy Administration Point) API, so that you can manage XACML policies in either XML (standard XACML) or JSON format. We
used the JSON format for _javascript_-based apps (e.g. web user interface) in particular.
That being said, I do not see the value of expressing policies in pure JSON. The storage / serialization format is irrelevant.
What matters is providing an easy means to write policy-based access control. That could either be via a UI (vendor/implementation-specific such as Axiomatics Policy Server) or via a lightweight syntax that is easy to read and write. This is why I think
we should focus our attention on ALFA instead. It's look more like a programming language that JSON does (JSON being declarative). The
ALFA Profile is here. Also, we've put a lot of efforts into samples on
Wikipedia. Our customers all use ALFA and we are aware of other third parties using ALFA on their own e.g. the Open Justice Broker Consortium and even WSO2.
Also, while we're at it, shouldn't we consider streamlining the policy language e.g.:
-
have conditions anywhere, not just rules
-
get rid of targets and only have conditions
-
do away with PolicySet > Policy > Rule and provide a simple Policy element whereby a Policy either contains a decision or a set of children
-
many more things...
To TC:
Have we had any discussion on converting the whole XACML Policy spec
to JSON? Currently, only the request and response are documented
in json form?
Have there been any requests for this capability?
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
David Brossard
VP of Customer Relations
--
Martin F Smith, Principal
|