Tuesday, September 8, 2015

Authorization for web services using XACML 3.0

In a blog post last year, I covered some authentication and authorization test-cases for Apache CXF-based web services that I uploaded to github. In particular, the cxf-sts-xacml demo showed how a CXF service can use XACML to authorize a web service request, by sending a XACML request to a Policy Decision Point (PDP) and then by enforcing the authorization decision. This demo only covered XACML 2.0 (provided by OpenSAML). In this post we will give an example of how to use XACML 3.0 via Apache OpenAz to make and enforce authorization requests for Apache CXF based services.

1) Introducing Apache OpenAz

The XACML functionality in Apache CXF is based on OpenSAML, which provides support for XACML 2.0. However, XACML 3.0 is an OASIS standard as of January, 2013. A new project in the Apache Incubator called Apache OpenAz addresses this gap. The source code is broken down into the following modules:
  • openaz-xacml - API + common functionality.
  • openaz-xacml-rest - Some common functionality used by the RESTful API interfaces
  • openaz-xacml-pdp - A PDP implementation
  • openaz-xacml-pdp-rest - An implementation of the XACML 3.0 RESTful Interface for the PDP
  • openaz-xacml-pap-rest - An implementation of the XACML 3.0 RESTful Interface for the PAP
  • openaz-xacml-test - Some testsuites
  • openax-pep -  The PEP (Policy Enforcement Point) implementation.
2) Integrating Apache OpenAz with Apache CXF

The testcases are available here:
  • cxf-sts-xacml: This project contains a number of tests that show how to use XACML with CXF to authorize a client request. It contains both XACML 2.0 tests and XACML 3.0 tests.
In both cases, the client obtains a SAML Token from the STS with the roles of the client embedded in the token. The service provider extracts the roles, and creates a XACML request. For the XACML 2.0 case, OpenSAML is used to create a XML XACML 2.0 request. This is then sent to a mocked PDP JAX-RS service. However, let's focus on the XACML 3.0 case. In this test, the OpenAz API (via the openaz-xacml module as covered above) is used to create a JSON XACML 3.0 request. This is evaluated by a OpenAz-based PDP which is co-located with the service. After evaluating the request, the PDP response is then enforced at the service side.

The service endpoint is configured in Spring as follows, registering a XACML3AuthorizingInterceptor (which in turn contains a reference to the co-located PDP):

The XACML3AuthorizingInterceptor is configured with a implementation to create a XACML 3.0 request using the SAML 2.0 profile of XACML 3.0, which is subsequently converted into JSON + sent to the PDP. The PDP is configured with "root" and "reference" policies, that state that a user of role "boss" has permission to "execute" the Web Service Operation "{http://www.example.org/contract/DoubleIt}DoubleItService#DoubleIt". For example:
A sample authorization request looks like:
If you are interested in XACML 3.0 please get involved with the Apache OpenAz project! Once the project gets more mature, the PEP code in my project will probably make it over to Apache CXF so that users have the option of supporting XACML 2.0 or 3.0 (and XML or JSON) with their web services.


  1. This comment has been removed by the author.

  2. Greate sample, but I can't get it running because it complains that it can not find the openaz 0.0.1-snapshot in the mvn repository.

    1. It should be fine now: http://repository.apache.org/content/groups/snapshots/org/apache/openaz/

  3. Thanks for the test cases. They are very useful to demonstrate PEP-PDP features in a real-world use case. For your information, I have adapted them for another XACML 3.0 implementation called AuthzForce. I made two test cases actually:

    1) One similar test case using a remote AuthzForce PDP as a REST service (the PEP-like CXF interceptor uses a JAX-RS client to call the RESTful PDP with XACML 3.0 requests);

    2) Another test case using an embedded (Java) AuthzForce PDP (the PEP-like CXF interceptor uses a Java API to call the PDP instead of XACML 3.0 requests, but the policies are still standard XACML 3.0 policy documents).