4 July 2019
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.
First, here’s an overview of XACML and how it works. Its key components are:
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.
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.
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.
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 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.
© All Rights Reserved 2019 PlainID