This blog post intends to give a short but concise introduction to the Policy Information Point (PIP) in the XACML reference model, specifically its role in the XACML architecture and how it is usually realized  in practice.

The idea of flexible and granular authorization lies at the very heart of Attribute-based Access Control (ABAC) in general, and XACML in particular. Traditional Role-based Access Control (RBAC) systems rely on single-dimensional categorization of authorized entities into different roles. While it is possible to extend the RBAC authorization scenario with one or two other dimensions, ABAC aims to tackle the problem at the root, by defining a scheme in which just any available information at the time and space where the decision is being made can be used in the authorization process. 

Just as a common saying goes: “Only the sky is the limit”, in this blog post we will get an introduction on how adopters of XACML can utilise the power of Policy Information Points to evaluate authorization decisions based on just about any property that can be exposed to the XACML decision engine.

Policy Information Point

For the purpose of this post, the readers are expected to be familiar with the XACML reference model. An excellent narrative introduction to the XACML architecture can be found in this blog post XACML Reference Architecture.

If we think of the PDP as the authorization engine, then the fuel needed by that engine is attributes and their values. That is precisely where the PIPs come into play – to provide attribute values when asked for by the PDP. According to the XACML standard:

Policy information point (PIP)
The system entity that acts as a source of attribute values

and it is given only a cursory mention in the data-flow model

479 6. The context handler requests the attributes from a PIP.
480 7. The PIP obtains the requested attributes.
481 8. The PIP returns the requested attributes to the context handler.

It seems like the concept is grossly simplified to the point that it might leave users scratching their heads wondering if that is really all that is to it. What does not make it to the surface of this definition is the complexity behind the process of obtaining attribute values and the possible interaction between the queried PIP and the querying XACML context during such a process.

A classic example is a PIP that provides the value of the attribute representing a user’s ROLE based on the user’s ID. In such a context, one could ask — what if there is no user’s ID available? How will the PIP respond in such cases? The correct answer is: it is up to the implementor of the PIP to decide. One PIP implementation can return nothing while the other can throw an error back to the caller. The bottom line is that the answer should make sense given the question being asked about the ROLE of the user being authorized and it is the responsibility of the caller to decide what to do with a received answer.

Simple PIP implementation

As mentioned above, the role played by PIP is to provide attribute values upon request from the PDP context. Using Java as example, a simplest PIP possible could be implementing the following

A slightly different approach might pass along the handler to the querying context for further interaction

As we have seen in the classic example of the attribute ROLE resolved by ID, typical attributes’ values in the application context are hardly static. In addition, a lot of times one attribute will require the resolution of other attributes, which may or may not be resolved by the same PIP. For example, the user’s APPROVAL_LIMIT may depend on the ROLE, which in turn, as we saw earlier, is resolved using the user’s ID.

A PIP can obtains its attribute value from just about any source available to its implementor. Common sources include relational databases via SQL, directories via LDAP and even flat-structured file such as CSV. It is worth noting that there is another class of attributes that are used by the authorization framework. These are attributes related to environmental information such as CURRENT_TIME, CURRENT_DATE etc. These attributes are strictly qualified as being provided by a PIP since the context handler conceptually has no other mean to resolve values except for those contained in the request context itself.

 PIP-arch

Conclusion

The concept of Policy Information Point is a simple yet powerful one, which encapsulate all the complexity of providing attribute values to the authorization context. As the application context grows, more and more attributes are required; thus requiring more PIPs to be added to the system. The more attribute sources are added into the system, the more versatile the authorization capacity becomes. 



Leave a Reply

Your email address will not be published. Required fields are marked *