OpenAz PEP Layer Now Available

The PEP layer is now available for the OpenAz project. You can find some very basic information on it here. I spent a decent amount of time working with the XACML guys on this layer. What I wanted to try to do was built a set of APIs that simplified building PEPs on top of the AzAPI (Java wrapper around XACML). The AzAPI, like XACML is very very powerful, but in the work that I do with customers, most of the time, customers are looking for some basic functionality. Based on patterns we've seen at a number of customers, we tried to make some very common PEP scenarios easy to implement with the this layer. In this post, I'll show how the OpenAz PEP simplifies building a PEP.

The Hello World PEP

AzService azService = new org.openliberty.openaz.pdp.provider.SimpleConcreteService();
PepRequestFactory pep = new PepRequestFactory(CONTAINER,azService);
PepRequest req = pep.newPepRequest("josh","hello","world");
PepResponse resp = req.decide();
System.out.println(resp.allowed());
       
if (resp.allowed()) {
 
      Map<String,Obligation> obligations = resp.getObligations();
      Iterator obligationsIt = obligations.keySet().iterator();
      while (obligationsIt.hasNext()) {
          String obligationName = obligationsIt.next();
          Map values = obligations.get(obligationName);        
          System.out.println(obligationName+"=>"+values);
      }        
}

The org.openliberty.openaz.pdp.provider.SimpleConcreteService is the example AzService (wrapper around XACML) that is there in the OpenAz project. Soon, we'll get an implementation of the AzService that uses the Sun XACML implementation.. Using the AzService we get a handle to the PEPRequestFactory. The PEPRequestFactory is used to generate one a PEPRequests. In the example, we're using the most basic for - simply passing in a String for the user, the action, and the resource. Once the request is generated, a response is returned and we can process the result. The response has a simple yes/no result, and then a handle to process the obligations. Obligations, as we've discussed on numerous occasions on this blog, can be used to have the PDP communicate additional responses to the PEP.

Features of the PEP Layer

The example above shows how simple doing very basic PEP calls, but there are a number of powerful features that are worth highlighting

Mapping of Native Java Objects - You can create a PEP request from any Java Object. This is done through the concept of "mappers". Each PEPequestFactory is configured with a set of Mappers. A mapper converts a Java object into a collection of attributes that XACML PDP can understand. This means that things like JAAS Subjects, Java Permissions, String, Sockets, custom objects, can be marshalled from their native form to XACML. Very useful is you want nice clean code.

Simplified Response Handling - As you saw in the example, the response is a simple yes/no and the Obligations are basically strings.

Handlers - You can add pre and post decision handlers to extend the functionality with caching (pre) or auditing (post).

Easy access to the full AzAPI - The main idea was to keep things simple at the PEP layer, but if implementations require the full AzAPI, you can start with the PEP layer, and the complete it by getting access to the AzRequestContext or AzResponseContext

What should I do next?

You can join the OpenAz mailing list, to follow and add to the discussion. Take a look at the project or sourceforge and contribute, or just give feedback on the API. A good place to start is with the tests. This shows some of the basic useage of the API.

Even the Longest Journey Starts with the Smallest Step - OpenAz

With this simple post to the XACML TC message list, it begins.

OpenAz is an effort to build a new standard open source API for authorization. The initial version of the API is based on XACML. Think of it as a standard way of interfacing with a XACML engine using Java. Now, XACML as a policy language definitely has its challenges - I dare a human being to author a meaningful policy in XACML - but the simple runtime model - a few objects - all based on attributes is pretty nice and flexible, and this is something worth building on.

I think we also have to honest and say that the existing Java standard authorization APIs - checkPermission and its JEE cousin JSR 115 - are not great general purpose authorization APIs. They are very tightly bound into the Java code level security. This is good when you're trying to protected Java applets from downloading malicious code, but presents some challenges in other contexts. On the plus side, the Java permissions API is totally standard and available - on all platforms, so you can reliably write to it - it been around for a long time.

There has been some thinking on converging the Java Permission and XACML models previously, but this is not explicitly the goal of Open Az. OpenAz ambitiously looks define a new ubiquitous standard that both PEP and PDP vendors can use to integrate against. My first foray into the OpenAz API will be on the PDP side...I'm looking to build a reference implementation of a PDP, but my true interest in this is on the PEP side. I hope that OpenAz will be the ultimate answer to Where have all the PEPs gone?

This one is definitely going to be a marathon, not a sprint, but I think that with both Oracle and Cisco making initial contributions, there is some strong industry interest which should hopefully spur adoption and consequently innovation. As always, I'm open to your suggestions, and it is open source, so feel free to get your hands dirty and help out.