Header Image

Securing Layer 7 Policies with Axiomatics

This tutorial was provided by Matt Crooke, Principal Technologist at First Point Global. It was originally published on his blog.


The Extensible Access Control Markup Language (XACML) is a general-purpose Access Control Language providing context-aware authorization decisions. In this tutorial, we will demonstrate how the Layer 7 XML Networking Gateway can provide centralized, fine-grained access control using the Axiomatics Policy Server (APS).


In this scenario, we will be using the APS Policy Decision Point (PDP) via the SOAP XACML PDP Service. The APS PDP evaluates XACML Access Requests against XACML Policies, providing permit/deny authorization decisions. The Layer 7 XML Networking Gateway will act as Policy Enforcement Point (PEP), in order to:

  • Capture service requests

  • Transform request context into XACML Requests

  • Interpret XACML Responses

  • Enforce authorization decisions

Below is the Layer 7 Policy for the RESTful Broker Service. The Broker Policy provides in-policy authentication and invokes the Evaluate Request using XACML SOAP PDP Policy Fragment to provide the XACML fine-grain authorization. Fragmenting the XACML Authorization keeps the core policy simple whilst providing a reusable XACML Authorization Fragment.

  • Line 2: The policy secures the Broker Service using SSL. This protects the credentials used to authenticate to the Gateway. 

  • Line 3: Service clients are required to provide a username/password via Basic Authentication.

  • Line 4: The credentials provided are verified against the Gateway’s Internal Identity Provider. Optionally, we could replace the Internal Identity Provider with LDAP or a Federated Identity Provider.

  • Line 6: Here, we have included the Audit Messages in Policy Assertion. As shown below, we have set the Audit Events level to Warning and saved the Broker Requests and Reponses. This provides a simple method to test and debug our policy. (Note that auditing settings should be limited to development and problem resolution.)

  • Lines 8-11: These lines set the input parameters for the Policy Fragment. Line 8 sets the APS instance we will use to evaluate the XACML Request. Lines 9-11 set parameters we will be using to build the XACML Request. In this case, we are using the authenticated user as the Subject of the XACML Request, the Service’s Gateway URL as the XACML Request Resource and the HTTP Method as the XACML Request Action. When securing SOAP Policies via XACML, implementers should consider setting the XACML Action to the SOAP Action.

  • Line 13: Once the parameters for the XACML Request have been provided, the Evaluate Request using XACML SOAP PDP Policy Fragment at line 13 is invoked. If the Policy Fragment determines access is denied, an HTTP Error Code of 403 (Forbidden Access) is returned to the service client. Execution of the Policy terminates within the Policy Fragment and the client’s request is not routed to the back end.

  • Line 15: If, however, the Policy Fragment determines access to the Broker Service is permitted, execution continues on line 15 and the client’s request is routed to the back-end Broker Service.

The illustration below shows the composition of the Evaluate Request using XACML SOAP PDP Policy Fragment.


The Policy Fragment contains several Add Audit Details Assertions used to audit the XACML Request/Response and SOAP Service Request/Response. When using the aforementioned settings for the Audit Messages in Policy Assertion, the output of these Audit Messages can be viewed via the Policy Manager’s Gateway Audit Events dialog.


The Set Context Variable Assertion in line 3 uses the xacml-subject, xacml-resource and xacml-action context-variables (see Policy lines 9-11) to create an XACML Request. The XACML Request is stored to the xacml-request context variable.

  • Line 5: The XACML Request is then wrapped in SOAP Envelope and stored within the soap-request Message context-variable. Storing the soap-request variable as a Message allows us to use the SOAP Request as an HTTP Request for a Route via HTTP(S) Assertion. The generated SOAP Request uses the InstanceAccessQuery2 SOAP Action. The xacml-instance context variable is provided to identify the APS Instance to evaluate the XACML Request.

The constructed SOAP request is sent the APS SOAP PDP using the Route via HTTP(S) Assertion (line 9). The result of the Routing Assertion is stored within the soap-response context variable.


  • Line 10: In this line, we use the Evaluate XPath Response Assertion against the soap-response context variable to extract the XACML Response from its SOAP Response wrapping.

  • Line 11: Using the responseXpath.element context-variable set by the XPath Assertion, we store the XACML Response within the xacml-response context variable. In this example, we log the xacml-request and xacml-responses as audit messages. Real-world policies should take care to examine XACML Responses for obligations. Depending on the nature of the obligation, handling could occur in-policy or be off-loaded to file, email, JMS or obligation service.

  • Line 13: To determine the decision from the XACML Response, we use an XPath Assertion to find the content of the Decision element within the SOAP XACML Response. 

  • Line 14: Next, using the responseXpath.result context variable (set by the XPath Assertion), we store the decision within the xacml-decision context variable.

  • Line 16: Now that we have retrieved the decision from the XACML Response, we need to determine if the policy should continue execution and allow access to the back-end service or terminate execution, returning a forbidden access error/message. At line 16, we include an At least one assertion evaluate to true Assertion. Within this, we nest two All assertions must evaluate to true Assertions.


The first All Assertion branch uses the Compare Expression Assertion to verify the XACML decision is not permit. This All Assertion branch will evaluate to true if the XACML decision is either deny or indeterminate. If this occurs, the Customize Error Response Assertion sets the HTTP Error Code to 403 and HTTP Response Message to access forbidden. The Stop Processing Assertion then terminates the policy.


Alternatively, if the XACML decision is permit, the first All Assertions branch will fail. At this point, the second All Assertion branch is evaluated, the Compare Expression Assertion will return true. This satisfies the All Assertion branch and At least one Assertion branch, allowing execution of the Policy Fragment and Policy to continue.


Finally, at end Policy Fragment, we export any context variables we would like to make available to the main Policy.


You have now seen how you can create a Layer 7 XML Networking Gateway PEP to secure your services using the Axiomatics Policy Server PDP. This example could easily be extended to include PEP caching of XACML decisions using the Look Up in Cache and Store to Cache Assertions. Additional enhancements could also include usage of obligation handling services and authentication services.

Securing Layer 7 Policies with Axiomatics