For Thursday: The Attribute Problem

One little publicized issue is what I call the paradox of ABAC. As we are all aware, one of the principles of ABAC is that only the PDP, which holds and evaluates policies, “knows” what Attribute values will be used to make any given access control decision. However, in order for the PDP to render a decision it must be given the values of the attributes referenced by the applicable policies.

XACML defines (or implies) three different ways of doing this, which may be combined. 1) Attribute values may be provided in the decision request. 2) If the PDP finds there are missing attributes which are required to make a decision it may return a decision value of Indeterminate-Missing Attributes and specify what attributes are required. This allows the PEP to fetch the missing values and retry the decision request with them added. 3) In addition, most PDP implementations have the ability to pause in the middle of an evaluation and fetch missing attribute values before proceeding to complete the policy evaluation.

The issue is that on one hand, there is usually no certain way to know which attributes are required, but on the other hand it may be inefficient or operationally inconvenient to pick up missing values one at a time after the initial decision request.

The OpenAz Project considered these issues and developed two different approaches to it, which may be applicable in different situations. I will briefly describe them here, more documentation is available at the OpenAz Project.

The first was the idea of mapper routines. It was observed that attributes used for access control decisions often appear in programs as language objects. Software developers don’t really think in terms of attributes, but rather objects which contain the attribute values as one or more fields within the object.

A mapper is simply a subroutine which takes a language object as input, extract the values and produces attribute values named and formatted for a decision request. Rich Levinson developed the concept and wrote some mappers as examples. I believe the concept and perhaps the code is being used in at least one large company.

The second idea was to define an interchange file format called AMF to distribute metadata about attributes. Basic datatype information and information about how to retrieve the values are associated with each named attribute. The type information is primarily for use by policy authoring and analysis tools. The retrieval information is used by Policy Information Points (PIP) to access the data.

The idea was that the AMF will be used to populate a data dictionary or used directly. The AMF can be generated manually or produced by scanning a set of policies, or an attribute repository. Any missing information could be added manually. One of the concepts is that attributes can be marked to indicate that they should be included in decision requests or that they should only fetched when they are referenced in a policy. By monitoring actual runtime use of attributes, the correct set of frequently used attributes can be provided with every decision request. Infrequently used attribute values can be provided on an as needed basis.

Code to drive PIPs from was developed by Ajith Nair of JPMC. I believe this is also in production use.

I would like to see the NCCoE investigate these concepts and further develop them, or perhaps develop even better ideas.

Hal

xacml message