XACML Usage Scenarios | Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management

The following sections identify a few scenarios where XACML can be used. XACML can be used as a centralized policy store for applications. It can also be used to provide access control for Web services. In addition, it can collaborate with SAML (using the SAML 2.0 profile of XACML 2.0) for implementation of single sign-on and sharing the same access control mechanisms with an enterprise.

Policy Store

XACML is an ideal technology candidate for use in implementing a centralized or distributed policy store because it can act as a data abstraction layer for the policy decision point. It can be implemented on top of any underlying data store platform, including directory server or relational database. If policy data are stored in a directory server or relational database directly, the policy retrieval will be strictly dependent on the underlying data store platform. If there are different policy store products running on heterogeneous data store platforms, then XACML will be a more flexible approach because it is shielded off from the underlying data store platform.

A distributed policy store refers to the scenario where customers partition the types of policies by geographical areas or by functional areas across different servers. This allows easier maintenance by the local administration. It is also possible to have multiple PEPs to process different types of policies by different partitions (for example, by geographical areas). This distributed architecture of the policy system is a common way to scale up the architecture and increase the capability of high-volume policy inquiries.

A centralized policy store refers to the scenario where customers have a single master policy store. This is useful for administering all types of security access control rules centrally. However, it also requires that the centralized policy store be highly available. Otherwise, any outage will be disruptive and impact all business services that rely on the access control policies.

Centralizing Security Policy for Web Services Security

Many Web services management products (such as AmberPoint, Actional, and Flamenco Networks) provide an access control mechanism for routing SOAP messages via a Web services proxy, or a Web services agent (refer to [WebServicesLifeCycle] for details). These proxies (Web services messaging intermediary) or agents (Web server or application server plug-in) usually act as a policy enforcement point that enforces access control policies for XML and SOAP messages. The associated Web services management server (aka policy administration point) allows defining and administering security policies for access to partial or full content of the SOAP messages by user groups or roles. These are ideal candidates for applying XACML technology.

Collaborating with SAML

SAML currently provides a mechanism for specifying policies and authorization decisions. There are constraints in the extensibility and flexibility of how to express rules and policies. In SAML 2.0, SAML enables collaborating with XACML, where SAML can share attributes and authorization decisions expressed in XACML. Details can be found at [SAML2Core] and [XACML2SAML2].

ebXML Registry

When service requesters discover and look up Web services from a service registry, there needs to be a reliable access control mechanism to protect the service registry. Many UDDI service registry implementations use database security for access control. However, the database-centric security approach usually provides primitive access control with read or write attributes. It does not support sophisticated rules, preferences, or even policy negotiation because it does not have a policy language.

ebXML registry open source implementation (http://sourceforge.net/projects/ebxmlrr/) uses XACML to implement an access control mechanism to discover and consume Web services. This allows more flexibility and extensibility in controlling who can access and under which condition the service requester can invoke the Web services. The ebXML registry stores the access-control policies and attributes in the registry and customizes a registry attribute finder module based on Sun's XACML kit.

ExampleXACML Using Sun's XACML Kit

Sun Microsystems has created an implementation of XACML and released it as an open source project with the 1.0 release of XACML. It is available on sourceforge.net (http://sunxacml.sourceforge.net/). The current XACML Kit version 1.2 supports the XACML 1.x specifications (and most of the XACML 2.0 specification) with APIS for creating, validating, parsing, and evaluating policies and authorization requests. The code is broken into separate packages that support specific elements of the specification and is designed to make it easy to use or extend the XACML specification as needed. For more details, see the Sun XACML programmer's guide at http://sunxacml.sourceforge.net/guide.html.

Sample Scenario

To illustrate XACML kit, we use a sample scenario where a subscriber of an online portal tries to access their own account profile and check for credit card payment information. Here we have the following requirements:

Only a premium member from "coresecuritypatterns.com" can access the URL http://www.onlinestore.com/sensitive/paymentinfo.html for their sensitive account information, including their own credit card payment information.
Any other users who do not have the e-mail address domain ended with "coresecuritypatterns.com," or who are not a premium member, cannot access the credit card information.
Successful access will be logged for audit control.
Invalid access from users who do not have the valid e-mail address domain "coresecuritypatterns.com" will be also logged for audit control.

The online portal uses XACML for access control. This example will use the following features of XACML policies:

Applying the constraint of premium member status for the account information access request. The element <condition> will be used to specify only premium member in the <target> can access the resource.
Adding one of the conditions to enable only service requesters with an e-mail address domain "coresecuritypatterns.com" can access the resource.
Illustrating the use of <obligation> element to log both successful read access as well as unsuccessful access for audit trail.

Sample Request

Example 7-13 shows a sample service request to access the URL http://www.onlinestore.com/sensitive/paymentinfo.html expressed in XACML. The request denotes a read request from a user maryj@coresecuritypatterns.com, who has a premium membership, to access the URL for her own account information. The subscriber clicks the URL, and the online portal (acting as a PEP) generates an XACML service request for a read request to the URL resource.

Example 7-13. Request to access sensitive payment resource

<?xml version="1.0" encoding="UTF-8"?> <Request xmlns="urn:oasis:names:tc:xacml:1.0:context"          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">     <Subject>       <Attribute           AttributeId=    "urn:oasis:names:tc:xacml:1.0:subject:subject-id"           DataType= "urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">         <AttributeValue>             maryj@coresecuritypatterns.com         </AttributeValue>       </Attribute>       <Attribute           Attribute                DataType=             http://www.w3.org/2001/XMLSchema#string                Issuer=                   "admin@coresecuritypatterns.com">         <AttributeValue>premiumMember</AttributeValue>       </Attribute>     </Subject>     <Resource>       <Attribute AttributeId=       "urn:oasis:names:tc:xacml:1.0:resource:resource-id"                  DataType=            "http://www.w3.org/2001/XMLSchema#anyURI">         <AttributeValue> http://www.onlinestore.com/sensitive/paymentinfo.html </AttributeValue>       </Attribute>     </Resource>     <Action>       <Attribute           AttributeId=      "urn:oasis:names:tc:xacml:1.0:action:action-id"           DataType=      "http://www.w3.org/2001/XMLSchema#string">         <AttributeValue>read</AttributeValue>       </Attribute>     </Action>   </Request>

Sample Policy

The XACML policy engine (acting as a PDP) receives the read request. It looks up any policies that are applicable to the request. Example 7-14 shows a sample policy to protect the sensitive payment resource. In plain English, the policy allows any subject with a group identifier "premiumMember" and with an e-mail address domain name "coresecuritypatterns.com" to have read access to the sensitive payment resource with the URI http://www.onlinestore.com/sensitive/paymentinfo.html. It also specifies that the policy will log any successful read action or any unsuccessful read with an invalid e-mail address domain name.

Example 7-14. Policy for the sensitive resource

<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    Policy    RuleCombiningAlgId=    "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">   <Description>      This policy states that users with a domain name      @coresecuritypatterns.com who are also premium members      should be able to read the sensitive document      http://www.onlinestore.com/sensitive/paymentinfo.html.      Both successful and invalid read request are logged using Obligation.      If users have a different domain name other than      @coresecuritypatterns.com, this policy will deny access.      If users with a domain name @coresecuritypatterns.com who      are NOT premium members this policy also deny their access.      This policy illustrates use of "Condition" within a      "Target" element to apply constraints to the read access      for the requester who are Administrator only. It also      provides an example of "Obligation"      to log successful read and log invalid access.   </Description>   <Target>     <Subjects>       <Subject>         <SubjectMatch MatchId=             "urn:oasis:names:tc:xacml:1.0:function:rfc822Name-match">           <AttributeValue              DataType=              "http://www.w3.org/2001/XMLSchema#string">                 coresecuritypatterns.com           </AttributeValue>           <SubjectAttributeDesignator               DataType=               "urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"               AttributeId=               "urn:oasis:names:tc:xacml:1.0:subject:subject-id"/>         </SubjectMatch>       </Subject>     </Subjects>     <Resources>         <Resource>           <ResourceMatch              MatchId=              "urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">             <AttributeValue                DataType=                "http://www.w3.org/2001/XMLSchema#anyURI">                http://www.onlinestore.com/sensitive/paymentinfo.html             </AttributeValue>             <ResourceAttributeDesignator                DataType=                "http://www.w3.org/2001/XMLSchema#anyURI"                AttributeId=                "urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>           </ResourceMatch>         </Resource>     </Resources>     <Actions>       <AnyAction/>     </Actions>   </Target>   <Rule Rule Effect="Permit">     <Target>       <Subjects>         <AnySubject/>       </Subjects>       <Resources>         <AnyResource/>       </Resources>       <Actions>         <Action>           <ActionMatch              MatchId=              "urn:oasis:names:tc:xacml:1.0:function:string-equal">              <AttributeValue                  DataType="http://www.w3.org/2001/XMLSchema#string">                  read               </AttributeValue>             <ActionAttributeDesignator                DataType=                "http://www.w3.org/2001/XMLSchema#string"                AttributeId=                "urn:oasis:names:tc:xacml:1.0:action:action-id"/>           </ActionMatch>         </Action>       </Actions>     </Target>           <Condition              FunctionId=              "urn:oasis:names:tc:xacml:1.0:function:string-equal">         <Apply FunctionId=         "urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">           <SubjectAttributeDesignator              DataType="http://www.w3.org/2001/XMLSchema#string"              Attribute/>         </Apply>         <AttributeValue            DataType=            "http://www.w3.org/2001/XMLSchema#string">            premiumMember         </AttributeValue>       </Condition>   </Rule>   <Rule Rule Effect="Deny"/>   <Obligations>     <Obligation        ObligationdocEmphStrong">LogSuccessfulRead"        FulfillOn="Permit">       <AttributeAssignment          Attribute          DataType=          "http://www.w3.org/2001/ XMLSchema#anyURI">urn:oasis:names:tc:xacml:1.0:subject:subject-id       </AttributeAssignment>       <AttributeAssignment          Attribute          DataType="http://www.w3.org/2001/XMLSchema#anyURI">          urn:oasis:names:tc:xacml:1.0:resource:resource-id       </AttributeAssignment>     </Obligation>     <Obligation        ObligationdocEmphStrong">LogInvalidAccess"        FulfillOn="Deny">       <AttributeAssignment          Attribute          DataType="http://www.w3.org/2001/XMLSchema#anyURI">          urn:oasis:names:tc:xacml:1.0:subject:subject-id       </AttributeAssignment>       <AttributeAssignment          Attribute          DataType="http://www.w3.org/2001/XMLSchema#anyURI">          urn:oasis:names:tc:xacml:1.0:resource:resource-id       </AttributeAssignment>       <AttributeAssignment          Attribute          DataType="http://www.w3.org/2001/XMLSchema#anyURI">          urn:oasis:names:tc:xacml:1.0:action:action-id       </AttributeAssignment>     </Obligation>   </Obligations> </Policy>

Example 7-15 shows the response to the read request. The PDP returns a status that indicates whether the read request is granted. If this is granted, the <Decision> element will indicate "Permit." If this is rejected, the <Decision> element will return "Deny." An error of any kind (such as missing attribute value) results in "Indeterminate." "NotApplicable" is the result if no available policies apply to the given request.

Example 7-15. Output from the PDP program

C:\XACML2\sunxacml-1.2\sample>java SimplePDP request\request.xml policy\policy.xml <Response>   <Result ResourceID=        "http://www.onlinestore.com/sensitive/paymentinfo.html">     <Decision>Permit</Decision>     <Status>       <StatusCode          Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>     </Status>     <Obligations>       <Obligation           ObligationdocEmphStrong">LogSuccessfulRead"           FulfillOn="Permit">         <AttributeAssignment             Attribute             DataType=             "http://www.w3.org/2001/XMLSchema#anyURI">             urn:oasis:names:tc:xacml:1.0:subject:subject-id         </AttributeAssignment>         <AttributeAssignment             Attribute             DataType=             "http://www.w3.org/2001/XMLSchema#anyURI">             urn:oasis:names:tc:xacml:1.0:resource:resource-id         </AttributeAssignment>       </Obligation>     </Obligations>   </Result> </Response>

Remark

These examples use Sun's XACML Kit version 1.2, which currently supports XACML 1.1. To run these examples in XACML 2.0, developers need to change the version number and the namespace (for example, xmlns="urn:oasis:names:tc: xacml:2.0:policy") in the XML header, and make any necessary XACML 2.0 changes.

Use of XACML 2.0 with SAML 2.0

XACML 2.0 and SAML 2.0 can be used together. In XACML 2.0, a SAML profile is defined. [XACML2SAML2] specifies OASIS-approved standard extensions to SAML for interoperation with XACML. The SAML profile in XACML 2.0 includes specifications for:

Mapping SAML Attributes into XACML Attributes
Sending a SAML authorization decision query to an XACML Policy Decision Point
Receiving an XACML response in the form of a SAML authorization decision statement from an XACML Policy Decision Point
Requesting one or more XACML policies from an online Policy Administration Point using a SAML policy query
Receiving XACML policies from online Policy Administration Points in the form of a SAML policy statement in a SAML assertion
Storing XACML policies in policy repositories in the form of SAML policy statements

Figure 7-10 illustrates the use of these SAML extensions with XACML (also refer to [XACML2SAML2] for more details):

Service requester initiates request to access a specific resource. The Policy Enforcement Point sends the resource access request to an XACML Policy Decision Point in a SAML authorization decision query (XACMLAuthzDecisionQuery in Step 1).
- The Policy Enforcement Point may obtain attributes in one of the following ways:
- The Policy Enforcement Point may obtain attributes directly from an online Attribute Authority using an AttributeQuery (Step 1a). This query returns an AttributeStatement in the SAML response (Step 2a).
- The Policy Enforcement Point may obtain attributes from a repository, where they were stored previously by an Attribute Authority in the form of SAML AttributeStatements (Step 4a).
The XACML Policy Decision Point evaluates the resource access request and decides additional attributes are needed. It can obtain these in one of the following ways:
- The XACML Policy Decision Point may obtain attributes directly from an online Attribute Authority using an AttributeQuery (Step 2). This query returns an AttributeStatement in the SAML response (Step 3).
- The XACML Policy Decision Point may obtain attributes from a repository (Step 4), where they were stored previously by an Attribute Authority in the form of SAML AttributeStatements (Step 5a).

Figure 7-10. Use of SAML 2.0 in XACML 2.0

This allows the XACML Policy Decision Point to augment the resource access request with additional attributes.

The Policy Enforcement Point may obtain attributes from the Attribute Authority or from the Attribute Repository that stores the attributes about the service requester or resource (AttributeQuery in Step 1a).
The Attribute Authority returns attributes in a SAML attribute statement to the Policy Enforcement Point (AttributeStatement in Step 2a).
The Attribute Authority creates an assertion of an attribute statement in the Attribute Repository (AttributeStatement in Step 3a), which also makes the attribute statement available to the XACML Policy Enforcement Point (AttributeStatement in Step 4a) or to the XACML Policy Decision Point (AttributeStatement in Step 5a).
The XACML Policy Decision Point evaluates the resource access request and decides to make a SAML attribute query with the Attribute Authority (AttributeQuery in Step 2).
The Attribute Authority returns with a SAML attribute statement (AttributeStatement in Step 3). This allows the XACML Policy Decision Point to augment the XACML Policy Enforcement Point's description of the resource access request with additional attributes.
The XACML Policy Decision Point may need to retrieve any policies relevant to the resource access request from the XACML Policy Administration Point or from the XACML Policy Repository (XACMLPolicyQuery in Step 4).
The XACML Policy Administration Point finds relevant policies from the XACML Policy Repository and creates a policy statement assertion (XACMLPolicyStatement in Step 5). These policies may be retrieved as follows:
- The XACML Policy Administration Point responds to the policy query with a policy statement assertion (XACMLPolicyStatement in Step 6).
- The XACML Policy Decision Point can also find relevant policies from the XACML Policy Repository (XACMLPolicyStatement in Step 7).
With the availability of relevant policies and attributes, the XACML Policy Decision Point is able to respond to the XACML Policy Enforcement Point with a SAML authorization decision statement (XACMLAuthzDecisionStatement in Step 8).
Alternatively, the XACML Policy Decision Point can retrieve necessary policies directly from the XACML Policy Repository.