Better Attributes Than Attributes Themselves
Working with policies that evaluate attributes can be a nightmare, so it is necessary to craft better attributes
Policy-driven administration is the core of sound access risk management, the basis for distinguishing easily between access that is policy-compliant and access that is not — this allows risk management efforts to be concentrated on exceptional access.
In the last two articles I focused on some details of my vision for policy-driven administration: detachment policies and eligibility policies. I touched only briefly on how attribute values could be interpreted by policies to control the assignment of identities to entitlements (and teams). A lot more could have been said, but I restrained myself from going into too much detail because the topic of using attributes in policies requires an entire article. This is that article.
Many practitioners mistakenly conflate policy-driven administration and attribute-based access control (ABAC) even though the distinctions are evident in their names:
Policy-driven administration is an administrative technology that automates the manipulation of the raw materials that are used to establish trust and enforce policies
ABAC supports the access enforcement mission of IAM (identity and access management) by allowing attributes that are available during runtime to be evaluated within policies to enforce more dynamic access controls
The source of confusion is obvious: both technologies rely on policies that evaluate attributes when making decisions. Referring back to the Four Pillars of IAM, the two central functions of IAM are enforcement and administration. Policy-driven administration applies to the administration function that is dominated by identity governance and administration (IGA), while ABAC applies to the enforcement function and is typically associated with externalized authorization management (EAM). It is incorrect to refer to the use of attributes in policies as ABAC when applied in the context of administration since IGA is not an access enforcement technology.
The Problems with Attributes
Despite the fundamental difference between policy-driven administration and ABAC, experienced practitioners on both sides have learned one important lesson: working with attributes in the context of policies can be a nightmare. There are three key issues that will be encountered when building and maintaining policies that interpret attributes:
Attributes and their values are usually controlled by others, and there are often delays when reflecting the current state in attribute values
The meanings of attribute values can change over time
There is often a desire to apply policies outside of what is supported by raw attribute values
Attribute update delays
Attributes often reflect state, so our obvious preference is for the attribute value to always represent the current state. For example, an attribute called cost_center may reflect the department to which an identity belongs. Values for such an attribute usually are controlled by the HR team. When a reorganization occurs and people get shuffled into new departments, it would be nice if those changes were reflected immediately. Yet it is common for the changes to occur in the business before they are reflected in HR systems. The delay might be only a day or two, but in some cases it can take a week or longer for the official records to catch up with facts on the ground.
When there is an inconsistency between actual state and the state reflected in attribute values, any policies that depend on those attributes will be out-of-synch. The implications may be the following:
Some users don’t get the access they should right away (automatically) based on policies
Some users retain access that might have been removed by policies if the attribute values were up-to-date
For users who don’t obtain access right away, this isn’t the end of the world. Users who need the access right away can usually request it and obtain approvals at the cost of some undesirable friction. Once the access is assigned, it should be converted automatically to a policy-based assignment once the attribute value is updated and the attachment policy is applied (assuming the user would have been assigned based on the policy originally if the attribute value update had not been delayed).
The removal case isn’t so bad, either. Recall from the discussion of detachment policies that many entitlement owners would prefer that access not be removed immediately when the attachment policy no longer applies. That’s why detachment policies should be available to offer additional options beyond immediate removal. However, there will be some cases where the access should be removed immediately. This where an override mechanism is necessary.
Broad changes to attribute values
Some reorganizations are merely clerical in the sense that attribute values may change without affecting the actual organization of the business. For example, a new HR system might bring with it changes to how attribute values are formed. I have been involved in multiple events of this kind. Such changes are rare, but when they occur they are a big deal.
Let’s use the cost_center attribute again as an example. Perhaps the original system allowed alphabet characters in cost centers, but the new system allows only digits. In this case, every employee’s cost center would need to change. When this happens, a mapping would be provided from old cost centers to the new ones. For systems that interface with the HR system, the legacy cost center usually continues to be provided for some time alongside the new cost center, but the legacy cost center would not be updated for employees as they move around the organization.
The problem with this is that there might be a lot of policies (hundreds, perhaps thousands) that refer to the legacy cost_center attribute and its values. Once the new cost centers are available, all of these policies would need to be updated to use the correct values. Updating these policies is rarely as simple as performing search-and-replace operations. Usually, such updates can be scripted somehow, but such solutions are rarely straightforward.
One issue that often emerges in regimes where raw attribute values are used in policies is that some policies may rely on the structure of attribute values to facilitate shortcuts such as substring-matching or regular expressions to reduce the verbosity of policy statements. Let’s say that a policy needed to reference a set of cost centers that all shared the same first few characters: instead of referencing each cost center value individually, the policy might have selected the desired cost centers by matching on those common characters. This is not the type of policy statement that could be caught easily using search-and-replace or even scripting.
Policy trickery
Often there is a desire to apply an existing policy to identities that don’t possess the required attribute values. Some may recognize this as the classic call center overload problem. Let’s say there is a set of policies that rely on a certain set of attribute values to identify people who work in a certain call center so that the necessary access can be assigned automatically. For some reason, a surge of calls causes that call center group to be overwhelmed and there is a desire for people from some other part of the business to help temporarily with the surge in call volume.
The easiest way to get these people the access they need would be to change some of their attribute values temporarily. However, HR would not likely be interested in making this change just for purposes of auto-provisioning users’ access. The next best option might be to apply an override mechanism as mentioned previously. However, most attributes accept only a single value and changing values in this way likely would cause some undesirable consequences such deprovisioning existing access that may still be necessary.
The other alternative would be to update the policies temporarily. This would definitely work, but it would not be a straightforward solution if multiple policies are involved — especially if the policies were owned by multiple individuals. How do we ensure that the policies are changed back when the temporary work assignments are no longer needed?
Crafting Better Attributes
If only there was a better solution to these problems… Let me draw your attention to the highlighted entity on a diagram that I shared in my discussion of business-friendly IGA:
Teams were referenced as one of three organizational dimensions for identities (along with organizations and hierarchies), representing the various groupings of identities that are meaningful to an organization for policy purposes. Specifically: “Team memberships are typically derived from identity attribute values, but it is also possible for teams to be assigned through requests.”
Like entitlements, teams (or whatever a solution might call them) should possess embedded attachment, detachment and eligibility policies. In terms of policy-driven administration, it is useful to imagine teams as a layer of indirection between identities and entitlements. Since team membership is intended to be derived from attribute values, teams could be considered useful substitutes for attribute references in entitlement policies.
Returning to the cost_center attribute example: Instead of having an attachment policy refer to a specific cost_center value, that policy could refer to the team representing that cost_center value. In other words, the policy could refer to the team with membership derived from the desired cost_center value (assume the following statements produce equivalent outcomes):
Raw attribute policy formulation: cost_center == “0100010100”
Team membership policy formulation: memberOf([Payroll Operations (0100010100)])
The team membership policy formulation could be a reference to an actual team entity, not just the name of a team as a string, so that the reference could survive any changes to the team’s name. This has the added benefit of making policies more legible, since it would be easier for various stakeholders to discern the intent of a policy from team references than raw attribute values. Just as logical operators could be used to join multiple attribute values to create unions or intersections, the same operators could be applied to team memberships.
A well-structured policy-driven administration implementation would enforce a convention that discourages the use of attribute references in entitlement policies, preferring team memberships instead. This would address the issue caused by broad changes to attribute values noted above by limiting the use of raw attributes in policy statements to teams. In the event that such a change to attribute values occurs, only the thin layer of team policies would need to be updated while leaving entitlement policies untouched.
Finally, teams allow the business to achieve access-related objectives that are often beyond their reach in environments where only attributes can be referenced in entitlement policies. In the case mentioned above where some people need to join a swamped call center temporarily to help with a high volume of calls, those identities could simply be assigned to the necessary team (or teams) through the request process to allow the downstream entitlement policies to automatically assign the necessary access. Furthermore, these request-based team assignments could take advantage of temporal access options to automate removal after a certain period of time. These team assignments would also be included in audit campaigns for future follow-up.
This is how teams could be considered better attributes than attributes themselves:
The added layer of indirection provided by teams helps insulate entitlement policies from changes that don’t affect the intentions behind them
Teams can have names that are more meaningful than raw attribute values, making them more legible in policy statements that reference them
Team memberships may be set primarily based on attribute-driven policies, but it is possible to assign additional identities to a team through the request process