Applying fine-grained access control in applications and APIs using Axiomatics Java PEP SDK

Today, code might look like this:

// Approve the PO
if (user.approvalLimit>=order.amount){
   	if (user.location.equals(order.location)){
          	if (user.id.equals(order.purchaser)==false){
                 	order.approve();
          	}
   	}
}

The code snippet above shows how developers might implement fine-grained authorization today. It is extremely specific and it binds the application directly to the authorization logic. What happens if the authorization rules change? What if there is another rule whereby a user must be in the purchasing department. This would call for another if statement:

// Approve the PO
if (user.approvalLimit>-order.amount){
   	if (user.location.equals(order.location)){
          	if (user.id.equals(order.purchaser)==false){
          	    if (user.department.equals(“purchasing”)){
                 	order.approve();
          	    }
          	}
   	}
}

Changing code in such a manner is slow and needs to go through a development / test / QA / production lifecycle which can be very time-consuming.
To avoid this, developers can use XACML, the eXtensible Access Control Markup Language. All developers need to do is use – what are called in the XACML lingo – Policy Enforcement Points (PEP) as described hereafter.

XACML Policy Enforcement Points (PEP)

A policy enforcement point (PEP) in the XACML architecture is responsible for:

  1. intercepting a business request (e.g. a user web request to a backend servlet)
  2. creating an authorization request using any number of attributes available from the business request and the context
  3. sending the request to the Policy Decision Point (PDP)
  4. receiving and enforcing the decision it gets back from the PDP

At Axiomatics, we call this process the SAFE process – it stands for Stop; Analyze; Forward; Enforce.

Implement Authorization Logic Using the Axiomatics PEP SDK for Java

The Axiomatics PEP SDK for Java provides developers with the means to easily develop any type of enforcement point. The PEP SDK decouples the creation of the XACML request from the specifics of the communication (or plumbing) of the PEP with the PDP. For in-depth documentation on the SDK, please refer to the SDK’s documentation and javadocs[djob1] .
The first step is therefore to create an instance of a PDP connection. The simplest way to do so is to use the SDK’s connection factory as follows:

PDPConnection pdp = PDPConnectionFactory.getPDPConnection();

The second step is to stop the business request and create an XACML authorization request from it. To do so, we need to create a XACML request that reflects the authorization request expressed in the code previously written. The code contained: order.approve(); . This means that the authorization request (or question) will be:

Q

Can user Alice approve order #123?

It moves the entire authorization logic – the policy – outside the application and inside the policy decision point. The application logic is simpler and agnostic of the authorization logic. The application code now becomes the following lines:

// 1. Create a connection to the PDP - abstracted away via connectors
PDPConnection pdp = PDPConnectionFactory.getPDPConnection();
// 2. Build the XACML authorization request
XacmlRequestBuilder builder = new XacmlRequestBuilder();
// 3. Add attributes - Can user Alice approve order #123?
...
// 4. Build the XACML authorization request
RequestCtx authzRequest = builder.buildRequest();
// 5. Invoke the PDP - evaluate
if (pdp.evaluate(authzRequest).getBiasedDecision()){
    order.approve();
}

The if() statement simply checks the decision returned from the PDP. It does not need to change or grow to cater for additional parameters. Rather, it is now a simple question to an external PDP. The question always remains the same but the policy can evolve.
In our example the policy was originally the following:

P1

A user can approve a purchase order if the user’s approval limit is greater than the purchase order amount and if the purchase order belongs to the user’s region and if the purchase order has not been created by that given user.

It was then enriched to cater for the department of the user in addition to identity, location, and amount:

P2

A user can approve a purchase order if the user is in the purchasing department and the user’s approval limit is greater than the purchase order amount and if the purchase order belongs to the user’s region and if the purchase order has not been created by that given user.

The change does not require any change on the application (PEP) side.
Let’s now focus on the actual creation of the XACML request. The way the request is built depends largely on the environment the developer wants to use (e.g. Servlet API…). In this example we will assume hard-coded values.

A request is made of attributes. Attributes are essentially key-value pairs that describe a user, resource, action, or the context of an authorization request. Role==manager is an attribute, so is actionId==view or currentTime==1PM. The request we have in mind here is “Can user Alice approve order #123?”. We need to break that request down into attributes, i.e. the user’s identity (Alice), the desired action (approve), the type of resource (purchase order) and the latter’s identifier (#123). Using the SDK, we can build the request as follows.

// 2. Build the XACML authorization request
XacmlRequestBuilder builder = new XacmlRequestBuilder();
// 3. Add attributes - Can user Alice approve order #123?
builder.addSubjectAttribute(Constants.SUBJECT_ID, "Alice");
builder.addActionAttribute(Constants.ACTION_ID, "approve");
builder.addResourceAttribute(Constants.RESOURCE_ID, "po#123");

The SDK provides utility methods to quickly add attributes to an existing request object. The richness of XACML is hidden away. For instance, a developer doesn’t need to specify the data type (string, boolean, URI…) unless absolutely necessary. The category is conveyed through the method name (addSubjectAttribute… addResourceAttribute…)

Benefits of the XACML PEP SDK for Java

Implementing fine-grained authorization using the Axiomatics XACML PEP SDK has several benefits:

  1. It decouples authorization logic from business logic.
  2. It lets developers focus on application logic and therefore be more efficient
  3. It promotes centralized authorization: the PEP requests an authorization decision from a policy server. It makes it easier to manage authorization, its lifecycle, and its change management

Conclusion

Writing enforcement points using the Axiomatics PEP SDK is quite simple. Developers should always strive to develop PEPs that are in line with the target environment’s best practices and framework APIs. PEPs should also be configurable and un-intrusive to promote reuse, easy configuration, and efficiency.
As a follow-up to this article, we recommend Java developers read the blog post on using XACML to apply fine-grained access control on Java Servlets, which will be published next. That article will follow the same structure and applies the PEP SDK to the Java Servlet API.

Other Blogs

3 keys to re-evaluate your authorization management
Business
On May 27, I had the pleasure to join the KuppingerCole KCLive event with several industry peers in a panel discussion about  “Enabling the Future...
How OAuth is related to Attribute Based Access Control
Tech
What is Authorization? Authorization, also referred to as Access Control, is the process that follows authentication (which checks your identity and ensures that you are...
Modern Enterprise Authorization Management System
Business
Gartner has an interesting article titled “Modernize Your Runtime Authorization” that highlights some aspects you need from a modern enterprise authorization systems. Over the years...