XACML: Alive or Dead?

In 2013, a Forrester analyst wrote a blog proclaiming that XACML (Extensible Access Control Markup Language) was dead. I think it’s safe to say that the last four years have proven him wrong.  While it has yet to achieve widespread adoption, XACML—a standard specification for attribute-based access control—is still around and gaining fans. If your organization hasn’t adopted XACML, there are several things you should know about it — and its very essential PDP component — that may convince you it’s time to embrace it.

The XACML Process

First, here’s an overview of XACML and how it works. Its key components are:

• Policy Administration Point (PAP): The PAP creates a policy or policy set and manages them.
• Policy Enforcement Point (PEP): The PEP handles access control by passing along decision requests and enforcing authorization decisions.
• Policy Decision Point (PDP): The PDP evaluates the requests based on the policies set by the PAP and sends back an authorization decision to the PDP.
• Policy Information Point (PIP): If there are missing attributes in the XACML request sent by the PEP the PIP finds them for the PDP so it can evaluate the policy.
• Policy Retrieval Point (PRP): This is where the XACML access policies are stored.

The access control process starts when a user sends a request for access. It’s received at a PEP. The PEP forwards the request to the PDP. The PDP evaluates the request. If needed, it asks the PIP for context attributes. The PIP collects these context attributes from the subject, resource, action, and environment and delivers them to the PDP. Context attributes are basically a set of conditions that must be met.

The PDP determines whether to grant access based on the security policies from the (PAP). It returns its decision to the PEP, which then either grants or denies access. We’ll go into more detail on this later, and discus the importance of the role the PDP plays.

The Role of Rules

Rules are integral to how XACML works and a key component in the hierarchy of decision making that determines access. A rule has target information, an effect, and a condition. The target is set of conditions that must be met for a policy set, policy, or rule to apply to a given request. The rule’s effect is to deny or permit access. The condition, which is optional, refines the applicability of the target. Rules can be separately evaluated, but they must be part of a policy.

A policy has target information as well, along with a rule-combining algorithm and obligations. The algorithm determines how rules are joined to convey the exact meaning of policies. An obligation is a directive from the PDP to the PEP for the requirements before or after access is approved. Since a policy specifies target information, a rule doesn’t have to do so. It can just use the information from the policy.

Then there’s the policy set, which includes a target, a policy-combining algorithm, policies, and obligations. The policy-combining algorithm specifies how the results of evaluating the component policies are combined.

Here’s where things get interesting. Rules can be reused in policies, and policies can be reused in policy sets. The ability to reuse these components makes it possible to build complex security policies without duplication. That’s just one of the advantages XACML offers.

PDP: Judge and Jury

One of major benefits XACML offers is its use of the PDP. Whereas the PEP serves as a gatekeeper of sorts — no access requests can slip in because they’re stopped by the PEP, the PDP serves as the judge and jury. It’s the PDP that will determine whether access is granted, and you can specify how the PDP makes it decisions.

When the PDP receives a request from the PEP, it looks for applicable policies. It does this by comparing the request to values in targets, which are the conditions for the subject, resource and action that must be met in a rule, policy or policy set to apply to a request. The target also is used to index policies, making it easy to store and access them. When the PDP receives a request, it can quickly go through the policies to find which ones apply.

Once the PDP finds an applicable policy, it will evaluate the policy, its rules, and any conditions within the rules. It will also look at attributes. Attributes are characteristics of the subject, resource, action, or environment in which the access request is made. For example, attribute values might be provided for a person’s name, role, and the service he or she wishes to access. The request the PEP sends to the PDP contains attributes, and the PDP will compare them to attribute values in a policy to make the access decision. Whereas the PDP is serving as the “judge and jury” to decide whether to grant access or not, you can set how the PDP makes its decisions.  For example, XACML provides a set of functions that allow you to specify how the PDP should handle the case of multiple attribute values.

XACML also includes safeguards at the PDP level. For example, a PDP will authenticate the identity of the PEP and assess the level of trust to determine if any sensitive data should be passed.  The PEP will also authenticate the identity of the PDP before it sends decision requests as well. The two basically team up to prevent unauthorized access by establishing “trust” before any information can be passed.

The Benefits of XACML

With XACML:

• Security policies are specified separately from where they are enforced. That makes it easy to immediately update them if a governing policy changes. It also means they can be reused in multiple enforcement places. Other changes are easier too as policies can be administered and deployed to defined architectural functions such as the PAP and PDP.
• Unauthorized requests never get to an application or service because they are stopped by the PEP. That makes it much harder to compromise the application.
• The use of target information in the authorization process provides a way to index policies. That makes it convenient to store numerous policies and then quickly sort through them to find which ones apply. When an access request is received, the PDP know where to look for applicable policies because the policies are indexed based on their target constraints.
• It can be used in any environment. Then there is the fact that XACML is comprised of components that can be standardized. For example, the PDP uses well-defined data as input and provides a well-defined interface to the PAP. That means an organization doesn’t have to implement its own PDP.
• There is support for a wide variety of data types, functions, and rules for combining the results of different policies. In addition, various standards groups are creating extensions and profiles to link XACML with other standards, which will increase the ways it can be used.
• The PDP provides access authorization as a service in the infrastructure. The algorithms can be removed from the application logic of individual information systems. They will then query the PDP via their own PEPs.
• A policy can be written that refers to other policies. XACML will combine the results from these different policies into one decision.
• Auditing at the PDP and PEP is simpler than auditing across disparate applications and services.
• Integration can occur at the API/web services gateway layer in a non-intrusive way to implement the right level of data sharing and enable new business models.
• Policies and rules provide for fine-grained authorization with higher level of abstraction.

The API Angle

XACML also makes a great API access solution. It provides for controlled access to APIs based on roles, attributes, and context, with the ability to deploy policies throughout the enterprise.  In addition, the externalized authorization layer enables business owners to be involved in API access decisions, ensuring compliance and risk mitigation are part of the API access strategy.

In addition, you can create an API to serve as a PDP to authorize access to applications.  Most developers embed authorization logic within application code. That makes it hard to maintain and integrate with external services providing extra authorization attributes. The PDP enables you to externalize the authorization logic and take advantage of flexible attribute-based access control features.  the externalized authorization layer enables business owners to be involved in API access decisions, ensuring compliance and risk mitigation are part of the API access strategy.

XACML: Alive and Well

XACML is here to stay, If you’re interested in learning more about it, as well as its PDP element, you’ll find the complete standard and other reference materials on the OASIS XACML web site

That being said, Attribute Based Access Control (ABAC) is not just XACML, policies are not expressed just in XACML, and there are disadvantages you should be aware of before adopting XACML – we’ll leave all that for our next blog on this subject.