Authorization using XACML in Datapower
1. Introduction
1.1. What is XACML
EXtensible Access Control Markup Language (XACML) is an open standard for defining authorization to a resource. XACML is an XML-based standard from OASIS (Organization for the Advancement of Structured Information Standards) that is useful in expressing and evaluating access control decisions on a protected system resource. Specifically, an XACML document represents a tree of policy specifications and tree/hierarchy structure is used to determine whether a policy or rule is applicable. XACML is designed to enable the interoperability of a broad range of administration and authorization products by providing a universal language for authorization policy. Its flexibility and features for supporting large scale, federated environments will literally set the standard for the next generation of authorization products,” explained Hal Lockhart of BEA Systems, co-chair of the OASIS XACML Technical Committee.
1.2. At a High Level
Figure 1
● Policy Enforcement Point (PEP) – the system entity that performs access control
● Policy Decision Point (PDP) – the system entity that evaluates applicable policy and renders an authorization decision
● Policy Information Point (PIP) – the system entity that acts as a source of attribute values
● Policy Administration Point (PAP) – the system entity that creates a policy or policy set
1.3. Where could XACML be used?
● Between PAP and PDP: a format for expressing policy information and could be in administration requests/responses. Also, could be in persistent form
● As a policy storage format: an access control database could be stored in XACML form
● As a policy interchange format: two communicating policy decision points may exchange policy information using XACML. A request may contain XACML policy information as a part of the handling policy for the information in the request.
2. XACML In Datapower:
2.1. How XACML can be used in Datapower?
Datapower supports XACML and is composed of two primary components: a Policy Enforcement Point aka PEP and a Policy Decision Point aka PDP. It is in the PEP where the information is extracted from the request (such as from a WS-Security header of a SOAP request) and generating an XACML message to the PDP for authorization permission. The responsibility of PDP is to either accept or reject the access to the dedicated resource. The PDP uses an XACML policy XML file to make the decision, which is written in a rules-based language defined by the XACML specification. What makes XACML powerful is how everything is open and standard — the communication between the PEP and PDP, as well as the XACML policy file itself. This means that if you change PDP vendors, which are often proprietary, the PEP can be left unchanged. Also, if you switch PDP implementations, you can re-use the XACML policies written for the old PDP. DataPower supports XACML authorization as part of its standard AAA (Authenticate, Authorize, Audit) framework as a PEP; it can serve as both the PEP and PDP as well. For the PDP, the location of the XACML policy file does not need to be on-box. For example, the policy can be fetched from an HTTP URL. The recently announced IBM Tivoli® Security Policy Manager supports XACML policies, and serves as an ideal central repository for authorization policies used by DataPower. As far as the XACML standard is concerned, Tivoli Security Policy Manager is a Policy Administration Point (PAP).
Figure 2
2.2. Configuring DataPower for XACML:
Step 1: Create XACML Policy file.
At a high level, XACML Policy should have following structure with XACML Policy Elements. Now you should have a basic idea how XACML engine processes XACML policies. Now let’s focus on how actual evaluation is taking place.
Figure 3
Mainly a XACML policy consists of 4 sub-elements. Those sub-elements are depicted in Figure 3.
Target Element: Every XACML policy should have a “Target” element. As described in “Applicability of XACML Policies” section, “Target” element decides whether a particular policy is applicable to a given request. The “Target” element contains 4 sub-elements. They are depicted in Figure 4.
Figure 4
At a high level, your policy file should look like some thing like this.
 |
Figure 5
Step 2: Configure XACML Policy Decision Point
Configure the XACML PDP object that specifies the location of the policy store directory:
1. From the WebGUI, click Objects Access Settings XACML Policy Decision Point to display the XACML Policy Decision Point catalog.
2. Click Add.
3. Update the following fields:
Name: SampleXACMLPDP
Other Policy Files from Directory : local:///xacmlPolicy.xml
XACML Policies Cache Lifetime: 300 (This number depends on expected policy update rate from Security Policy Manager.)
4. Click Apply to save the changes to the running configuration.
5. Optional: Click Save Config to save the changes to the startup configuration.
Step 3: XACML PEP Request.
Create an XSL file which parse’s the incoming request, gets the necessary information and passes it to PDP. For instance refer Figure 6
 |
Figure 6
Step 4: Configuring the AAA policy for XACML.
a) Extract Identity: Select Password-carrying UsernameToken Element from WS-Security Header.
b) Authenticate: Pass Identity Token to the Authorize Step
c) Map Credentials: None
Alternatively, the authentication can be done with AAA info file, however, our main intention here is Authorization with XACML.
d) Extract Resource: Local Name of Request Element (Resource can be extracted any way; however, I would be keen on Local Name from the request).
e) Map Resource: None
f) Authorize:
Method: Use XACML Authorization Decision
XACML Version: 2.0
Use on Box PDP: True
Policy Decision Point: SampleXACMLPDP (remember, this object was created in Step 2).
AAA XACML Binding Method: Custom Style Sheet
Custom Style sheet to Bind AAA and XACML: {xsl file created in step 3}
Keep other properties as default.
g) PostProcess: Set all the properties to false, as we do not wish to do any further changes to the request.
h) Save all the changes.
Step 5: Attaching the AAA policy to your service.
Once the AAA policy is created, it is now ready to be attached to AAA action and used in service. Create a processing policy with AAA action and configure with AAA policy created in step 4. Your service is now ready for test. Execute your service with different request and understand how it behaves for different scenario.
3. References:
