Using JSON and REST profiles for external authorization

In this blog post we describe how the recent JSON and REST profiles of the XACML standard make it easier to use and to integrate with the externalized authorization services provided by the XACML Policy Decision Point (PDP).

What is XACML?

The eXtensible Access Control Markup Language (XACML) is one of the most prominent Attribute Based Access Control (ABAC) systems in use today. ABAC systems use the concept of attributes (the properties of entities) to enable fine-grained access control rules enforcement. It is an OASIS consortium standard, version 3.0 of which was standardized in January 2013.

What are XACML profiles?

The core XACML specification covers three major parts – the reference architecture, the policy specification language as well as the request/response scheme. The profiles provide a way to enhance the core XACML standard by making it easier to extend it for specific needs. There are two kinds of XACML profiles:

  1. Profiles that extend the technical scope of XACML. Such profiles require a technical implementation on behalf of the evaluation engine (the PDP) used. Such profiles include the SAML profile of XACML, the Multiple Decision Profile, and the Administrative Delegation Profile and the REST and the JSON profiles that we will be discussing in this blog post.

  2. Profiles that define best practices on how to use XACML to express well-defined scenarios such as export control, intellectual property protection, and role-based access control. These profiles do not require any particular technical implementation changes on behalf of a XACML PDP engine other than the core XACML support. These profiles typically define a set of common attributes, their identifies, their possible values, and their use in possible policies.

Life before REST and JSON profiles

The core XACML standard laid out the specification for how a request to the PDP should be formulated in terms of specifying the attribute and its values in an XML notation. XML by nature is verbose, expensive to parse and is not supposed to be readable by humans.

At the same time, the standard does not specify the exact communication protocol that should be used by the PEPs to communicate with the PDPs. The majority of the XACML implementations expose the PDP authorization service as a SOAP Web Service, which means that the PEP would uses SOAP communication protocol to exchange XACML requests and responses with the PDP. Since different implementation would thus involve different SOAP wrapping, it becomes necessary to use vendors specific SDKs to implement a PEP that can communicate with the vendor implementation of the PDP.

The JSON and REST profiles are aimed at rectifying these shortcomings that have been identified with the core XACML specifications. This makes it easier for developers working at the level of XACML requests and responses to integrate existing or new systems with the XACML architecture in a much simpler and lightweight manner.

REST profile

To address the problem of existence of proprietary SOAP-based interface implementation of the PDPs, Remon Sinnema (a fellow member of the XACML Technical Committee) designed an XACML profile which defines how to expose XACML authorization as a REST-like service. In the profile, an XACML request can be sent as either JSON or XML. The response comes back in the same format (JSON or XML).

As explained in an earlier blog post, exposing a PDP as a REST-like authorization service provides several benefits:

  • It is standardized: the profile defines which headers need to be passed and what the format of the payload should be. Any profile-conformant service exposes the same interface and is therefore interoperable with clients that conform to the same standard.

  • REST is easier to integrate with: while languages like Java and .NET have good support for SOAP, other languages like PHP, Python, and Ruby may not. It becomes simpler to create a PEP that POSTs data instead and conforms with a REST-like architecture.

  • It is more efficient: if the SOAP overhead is eliminated, the overall message becomes smaller which means the transfer between client and service will be faster. Efficiency can be further augmented if JSON is used instead of XML to encode the XACML request and response.

Axiomatics Policy Server natively supports the REST profile with its version 6 release.

JSON profile

As mentioned before the XML format used in the exchange of XACML requests and response between the PEP and the PDP is verbose, inefficient to parse and not readable by humans. This makes the use of XML unfavorable in several situations.

To rectify this issue, our very own David Brossard designed the JSON profile to be used in conjunction with the REST profile (pdf) to support a JSON based messaging format for the XACML request and response messages.

JSON (JavaScript Object Notation) has been designed to be a lightweight data-interchange format that is easy for humans to read and write and easy for machines to parse and generate.

The JSON profile is a close mirror of the XML-based XACML request / response. However, it provides optimizations where possible. For example, it is possible to omit information and use inference by specifying reasonable defaults. For example, the String datatype doesn’t have to be explicitly specified. It also inherits the datatypes from Javascript ( Numeric, String, Boolean etc.)

Axiomatics Policy Server natively supports the JSON profile with its version 6 release.

Webinar on REST and JSON profiles

Recently David Brossard (author of the JSON profile) and Gerry Gebel (the president here at Axiomatics) conducted a Bootcamp series webinar on the use of REST and JSON profile to make development and integration easier. You can find a recording on this webinar, which covers more details of the profile, including example code, PEP demos etc, below.


Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...