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.