, , , , , ,

The Extensible Access Control Markup Language (XACML) is a general-purpose Access Control Language providing context-aware authorization decisions.  In this blog we will demonstrate how the Layer 7 XML Networking Gateway can provide centralised 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), capturing service requests, transforming request context into XACML Requests, interpreting XACML Responses and enforcing 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.

The policy secures the Broker Service using SSL (line 2); this protects the credentials used to authenticate to the Gateway.  Service clients are required to provide a username/password via Basic Authentication (line 3); the credentials provided are verified against the Gateway’s Internal Identity Provider (line 4).  Optionally we could replace the Internal Identity Provider with LDAP or a Federated Identity Provider.

In line 6 we have included the Audit Messages in Policy Assertion.  As shown below, we’ve 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: auditing settings should be limited to development and problem resolution.

Policy lines 8-11 set the input parameters for the Policy Fragment; line 8 sets the APS instance we’ll use to evaluate the XACML Request. Whilst lines 9-11 set parameters we’ll 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.

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 a 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 backend.  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 backend 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 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.

The XACML Request is then wrapped in SOAP Envelope and stored within the soap-request Message context-variable (line 5).  Storing the soap-request variable as a Message allows use to use the SOAP Request as a 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 identity 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.

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

Using the responseXpath.element context-variable set by the XPath Assertion we then store the XACML Response within the xacml-response context variable (line 11).  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.

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 13).  Then using the responseXpath.result context variable (set by the XPath Assertion), we store the decision within xacml-decision context variable (line 14).

Now we’ve retrieved the decision from the XACML Response, we need to determine if the policy should continue execution and allow access to the backend 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.

Alternately 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.

Lastly at end Policy Fragment we export any context variables we’d like to make available to the main Policy.

You’ve 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.