+

Authoring Multiple Decision Profile requests

This blog post describes some non trivial scenarios that an access control or authorization developer may encounter and provides several ideas to simplify them by utilizing features available in Axiomatics PEP SDK for Java.

Policy Enforcement Points, usually abbreviated as PEPs, are the endpoints in the XACML Reference Architecture where authorization questions specific to the business application are formulated and their resulting decisions are enforced. An authorization question comprises of attributes grouped into subject, resource, action, environment and possibly more custom categories, and the corresponding values for each such attribute. Consider a very simple access control scenario, where a user named Alice is trying to access a protected document named ledger. The equivalent XACML Request formulated at the PEP looks as below 

Access Control Question

Can the user Alice access the ledger document?

XACML Request issued by the PEP

Request = {(Subject:user=Alice) (Resource:document=ledger)}

The code to build this request using Axiomatics PEP SDK for Java follows

Request xacmlRequest = new XacmlRequestBuilder()                     .addSubjectAttribute("user", "Alice")                     .addResourceAttribute("document", "ledger")                     .build(); 

The Policy Decision Point (PDP), the component in the XACML architecture responsible for processing the access control requests from the PEP, responds to such a question with a single decision, which typically is a Permit or a Deny.

Need for a Multiple Decision Profile

The nature of access control scenarios a PEP may have to handle are usually much more complicated that the simple scenario described above. The number of attributes in each of the categories will be higher and certain attributes may contain multiple values. PEPs may often need to ask several access control questions, with different subsets of them having overlapping attributes and their corresponding values. A naive way to handle scenarios of this kind is to generate individual requests for every access control question in hand. This is evidently suboptimal for the reasons below.

  1. In a typical XACML deployment, the PDP will be run as a separate networked component. Each call from the PEP to a PDP involves use of network resources to establish the communication link and sustain the session or channel. A large number of such calls is time and resource inefficient and may slow down the hosting business application.
  2. The amount of information passed from the PEP to the PDP is also not optimal. Wherever, several access control questions contain overlapping attributes and attribute values, it should be possible to reuse this shared information across several questions/queries and hence minimize the aggregate network payload.

In order to handle this common scenario, XACML defines a Multiple Decision Profile, MDP in short, a scheme for PEPs to formulate many access control queries in a single XACML request in an efficient way, and accordingly obtain a set of responses from the PDP, one for each individual query.

Methods of Multiple Decision Profiling

Let us examine two of the several constructs available in the XACML specification for Multiple Decision profile.

By repeating attribute categories

Consider a situation where a PEP has to know which of the 4 users named Alice, Bob, Carol and Dave are allowed to access the ledger document. Using the regular request construct, the PEP would have to issue four different requests to the PDP, one for each user. It is possible to combine these four questions into a single request, by repeating the subject category alone four times, with each instance having the user attribute value as each of these users, and the resource category appearing only once, since it is the same document for all users. Such a request can be represented as:

Request = {(Subject:user=Alice) (Subject:user=Bob) (Subject:user=Carol) (Subject:user=Dave) (Resource:document=ledger)}

Upon receiving the request, the PDP isolates each of the repeated subject categories and considers them, in conjunction with the only resource category, one at a time and thus infers four different access control questions. The response from the PDP contains four individual decisions. Following below is the code snippet from Axiomatics PEP SDK for Java to construct this request.

Request xacmlRequest = new XacmlRequestBuilder()                     .addSubjectAttribute("user", "Alice")                     .bundle(Constants.SUBJECT_CAT)                     .addSubjectAttribute("user", "Bob")                     .bundle(Constants.SUBJECT_CAT)                     .addSubjectAttribute("user", "Carol")                     .bundle(Constants.SUBJECT_CAT)                     .addSubjectAttribute("user", "Dave")                     .bundle(Constants.SUBJECT_CAT)                     .addResourceAttribute("document", "ledger")                     .build(); 

 The bundle(String category) method above indicates that the named category should be repeated in the XACML request, and the category comprises of all the attributes and their values added after the previous bundle call on that category until the current call to the bundle(...) method.

This example as we notice, contains 4 subject category instances and 1 resource category instance. Hence, the PDP infers 4 X 1 individual requests.

To extend this concept, in general, if the number of instances of individual categories in a request are N1, N2, N3 … Nk respectively, the PDP interprets the request as consisting of N1 X N2 X N3 … X Nk independent access control questions and responds with as many decisions, each decision for the individual request defined by this Cartesian product of sets of attributes.

Reusing the attribute values in several access control questions, as above, efficiently minimizes the information transmitted across the network. However it has a drawback. Assume a situation involving two users, Alice and Bob, and two documents, the ledger and the customer profile document. Assume that the PEP is interested in knowing whether Alice can access the ledger document and Bob can access the customer profile document. An MDP request by repeating both the subject and resource categories looks as below.

Request xacmlRequest = new XacmlRequestBuilder()                     .addSubjectAttribute("user", "Alice")                     .bundle(Constants.SUBJECT_CAT)                     .addSubjectAttribute("user", "Bob")                     .bundle(Constants.SUBJECT_CAT)                     .addResourceAttribute("document", "ledger")                     .bundle(Constants.RESOURCE_CAT)                     .addResourceAttribute("document", "customer profile")                               .bundle(Constants.RESOURCE_CAT)                     .build(); 

Since there are two instances of each, the subject category and the resource category, the PDP infers four (2X2) individual access control questions {(Alice,ledger) (Alice,customer profile) (Bob,ledger) (Bob,customer profile)} and responds back with four different decisions, although only two of these are relevant to the PEP. The PEP, did not need to know if Alice can access the customer profile document or if Bob can access the ledger. The PDP hence evaluates some unnecessary combinations of attributes corresponding to such irrelevant and spurious access control questions. The next MDP method addresses this issue and allows selection of a subset of the Cartesian product of the repeated attribute categories.

By references to attributes

A request constructed using this method can be visualized as being made up of two parts.

The first part solely accumulates all the attributes and their values into corresponding categories. As in the previous method, here too, categories should be repeated to indicate those attributes which can have multiple values. In addition, each instance of such a repeated category is made referable by associating an identifier to it.

The second part weaves together individual access control questions by using these references. For each such question, this part describes the comprising attributes (and the categories containing them) by enlisting the reference identifiers defined in the first part of the request.

The PEP can use this MDP method to formulate the question “Can Alice access the ledger document? Can Bob access the customer profile document?”, which was only sub optimally possible using the previous MDP method. Below is the code using Axiomatics PEP SDK for Java 

Request xacmlRequest = new XacmlRequestBuilder()                     //first part adds all the attributes into respective                     //categories and associates a reference identifier to                     //each such category                     .addSubjectAttribute("user", "Alice")                     .bundle(Constants.SUBJECT_CAT, “AliceCategory”)                     .addSubjectAttribute("user", "Bob")                     .bundle(Constants.SUBJECT_CAT, “BobCategory)                     .addResourceAttribute("document", "ledger")                     .bundle(Constants.RESOURCE_CAT, “ledgerCategory”)                     .addResourceAttribute("document", "customer profile")                                               .bundle(Constants.RESOURCE_CAT, “customerProfileCategory”)                     //the second part weaves individual access control questions by                     //aggregating respective references to the categories                     //containing corresponding attributes                     .addMDPRequest(“AliceCategory”, “ledgerCategory”)                     .addMDPRequest(“BobCategory”, “customerProfileCategory”)                     .build(); 

In the above code, the method bundle(String category, String referenceId) repeats the named category by creating a new instance of it, and associating the given referenceId to this category instance. The method addMDPRequest(String[] referenceIds) then takes a list of all the referenceIds of the category instances which collectively comprise a specific individual access question. The PDP subsequently evaluates only those questions explicitly constructed in this manner.

If there are more attributes which should be present in all the individual questions defined using the addMDPRequest(...) methods, they can simply be added to their respective categories without associating a reference identifier to any of these categories. The PDP then includes these attributes in each of the reference based MDP access control questions.

Choosing the right MDP method

If every access control question in the Cartesian product obtained by repeating categories in the MDP request is relevant and necessary, then, creating a Multiple Decision request by repeating categories is the right choice. Also, in such a scenario, the process of constructing an MDP request by repeating categories is easier to understand compared to using references to attributes and categories. This is because one need not track sets of references that make up specific access control questions.

However, if only a subset of all possible access control questions are relevant, then the spurious questions generated in an MDP request that uses repeated categories, as seen in the examples above, consumes additional computation time at the PDP. On the other hand, using reference based MDP consumes extra memory at the PEP to store all the references and their associated aggregations to formulate all the relevant questions.

In a situation of this kind, one may have to measure the memory and time characteristics of the application containers hosting the PEP and the PDP, while using an MDP based on references and compare it to corresponding numbers measured while using an MDP with repeated categories. This comparative study can assist in choosing the right option, based upon the hardware characteristics and performance demands of the business application.

Conclusion

While externalizing authorization simplifies business application code and makes it more maintainable, certain access control scenarios can be tricky to handle. Multiple Decision Profile proves handy in such situations and provides a mechanism to optimize the PEP implementation. The Axiomatics PEP SDK for Java provides rich constructs to author complex MDP requests.

Related Articles

Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...
Response to White House meeting on cybersecurity and NIST updates | Dynamically Speaking
Dynamically Speaking
Our customers tell us constantly – security challenges continue to evolve and become more complex almost daily. It’s why we engage in conversations with enterprises...