Governance in Run-time Access Control World

The Yin and Yang of Governance for XACML

I chuckled when I read Ian Glazer’s blog post, “A Chronic Identity Pain.” Ian referred to himself as “an old provisioning guy” – being a few years his senior, it made me think, “Does that make me an old-old provisioning guy?” 🙂 Having said that, I do consider myself more of a governance and provisioning guy now, so maybe I get a break when it comes to managing and governing a run-time access control decision environment.

But back to Ian’s post. With it, he kicked off an important conversation topic: When you take off the infrastructure hat and put on the governance/compliance/management hat, a XACML, or claims-based access control environment, poses some very interesting challenges. As Ian said, understanding who really does have access to what can become a lot more challenging. I agree with him about there being a need for coordination between administration and configuration. I would add that a new level of change control is needed given the growing audit requirement for attestation. I would also point to the value of modeling and intelligence in these environments.

To better explain these points, take a look at this standard view of a XACML attribute based access control model:

In this graphic, you can see the request for resource access flowing into the PEP [at 1] and the PEP requesting policy and obligations from the PDP [at 2]. In this view, there is nothing too interesting from a governance perspective – although this flow has to be trustworthy and we’ve got to be able to track and audit its execution.

Then the PDP starts to run a cycle of dependencies that can get quite interesting. First, it obtains its policy from a PAP [at 3] that manages all the complex policies needed to control access. These policies contain the rules and obligations that make up the “Yin” of any governable run-time access control model. These policy rules are the heart of the access control model and must be governed accordingly. Questions such as: “Who defines them?” “Who approves them?” and “How do you manage their change control live-cycle?” should be of prime concern to any identity audit process.

On the other side, there must always be a “Yang,” and in this model it becomes the attributes, or run-time values that are being used in the rule assessment process. These resources, environment and subject attributes (data) are either presented in the session as claims (which are even harder to audit) or they are collected by the PEP from a process XACML calls a “policy information point” or PIP [at 4].

When the policy says “you can access the data IF your department attribute = accounting,” the system immediately places a high dependency on the integrity and governance of that department attribute. And we’re back to those same questions of “who sets the attribute?” and “who controls its life-cycle?” These questions are a primary concern for any diligent identity audit process. The policy absolutely “depends” on the attribute (just as the Yin depends on the Yang), and therefore the integrity, trust and governance of the overall access control process depends on the overall change control and attestation process that govern the policies and the attributes used in the system.

There’s one more thing to consider here, and that is intelligence. I think of the rules and the attributes in XACML (the Yin and Yang) as the “should’ in the question of “who should have access to what?” When I put my old provisioning guy’s identity governance hat on, I want to answer the question “who could” have access to that thing?” But in today’s emerging dynamic and highly distributed access control models, I can really only answer that “could” question when I have visibility into the policies and the attributes and can apply analytics, intelligence and modeling and ask the question “what if” … but I’ll save that discussion for another post.