- Identity ManagementCore Issues
- Understanding Network Identity and Federated Identity
- Introduction to SAML
- SAML Architecture
- SAML Usage Scenarios
- The Role of SAML in J2EE-Based Applications and Web Services
- Introduction to Liberty Alliance and Their Objectives
- Liberty Alliance Architecture
- Liberty Usage Scenarios
- The Nirvana of Access Control and Policy Management
- Introduction to XACML
- XACML Data Flow and Architecture
- XACML Usage Scenarios
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
XACML Data Flow and Architecture
XACML has a domain model expressed in XML Schema. A data flow diagram can better depict the logical components of XACML and how XACML interacts with other components. Figure 7–9 shows how XACML [XACML11] processes a service request to retrieve the attributes and policies. The following outlines the data flow in chronological sequence:
- The policy administrator defines policies and policy sets at the policy administration point. <VariableDefinition> and <VariableReference> elements support reuse of portions of a policy, which provides a macro capability.
- The service requester issues a request to the policy enforcement point to access the specified resource. This requires fetching the attributes and policies associated with the resource, the action, the environment, and the service requester.
- The policy enforcement point sends the request for access to the XACML context handler in native request format. This may include the details of attributes of the subjects, resources, actions, and environment.
- The context handler creates an XACML request context and sends a policy evaluation request to the policy decision point.
- The policy decision point queries the context handler for attributes of the subject, resource, action, and environment needed to evaluate the policies.
- The context handler obtains the attributes either from the request context created in Step 4, or it queries a policy information point for the attributes.
- The policy information point returns the requested attributes to the context handler.
- Optionally, the context handler includes the resource in the context.
- The context handler returns the requested attributes to the policy decision point. The policy decision point continues evaluating the policy as attributes are made available.
- The policy sends the response context (including the authorization decision) to the context handler.
- The context handler responds to the policy enforcement point, after translating the response context to the native response format of the policy enforcement point.
- The policy enforcement point executes any relevant obligations.
Once the policy is evaluated successfully, the policy enforcement point will either grant access to the service requester for the targeted resource or deny the access.
)
Figure 7–9 XACML data flow
XACML Architecture
XACML provides a standard virtual interface between the policy decision point and the service requester. Because XACML is a policy language set, it is difficult to define a specific technical architecture. XACML can support a variety of underlying infrastructures for policy stores. In summary, XACML has the following key logical architecture components:
- Context Handler. The context handler transforms service request formats into a format that XACML understands. Architects and developers may need to custom-build processing logic in the XACML context handler to handle the conversion between different service request formats.
- Policy Decision Point. The policy decision point (PDP) evaluates the resource access request against the relevant rules, policies, and policy sets. Architects and developers may customize their PDP by building a PDP application as reusable Java components (such as EJB) or simple servlets. Sun’s XACML implementation provides a sample PDP.
- Policy Repository. The policy repository stores the rules, policies, and policy sets that XACML accesses. XACML does not define any standard interface, and leaves it to the implementation to provide an interface to create or retrieve policy objects from the policy repository. Architects and developers may use an existing directory server infrastructure to store all policy objects using LDAP, or they may opt to implement the policy repository using a relational database if their current entitlement application architecture is database-centric.
There are some distinctive architectural aspects in XACML. XACML stores the policy objects in a hierarchy relationship of policy sets, policies, and rules. XACML is defined to have the policy, rather than the rule, be the smallest retrievable policy object. This is different from a traditional rule engine where architects and developers can directly retrieve a specific rule or attribute element. Rules can be implemented as one-rule policies to achieve effective retrieval at the rule level.
In addition, an XACML solution can operate on a variety of infrastructures, depending on how customers implement the policy decision point, the policy enforcement point, and the policy information point. The XACML reference implementation from Sun can run on a Web container (Web server) or an EJB container (application server). These have created flexibility and agility for XACML solutions to interoperate with heterogeneous infrastructures.