I’m a provisioning guy; it was the way I was raised in the world of identity management. And being a provisioning guy my take on how people are enabled to execute business transactions looks like this:
- Write a provisioning policy such as people in department 10 get LDAP group Q
- Enforce that policy – give people in department 10 group Q
- People get to do cool stuff
In a push-based scenario, this process works so long as the provisioned resource makes it’s own authorization decisions.
Let’s consider a WAM person’s take on how people get access.
- Write an access control policy such as to access this resource you need to be a member of LDAP group Q
- Enforce that policy – check for group Q membership
- People get to do cool stuff
This approach works too – except it makes the huge assumption that the people who show up wanting to do cool stuff are already members of LDAP group Q.
What if the resource to which we want govern access does use WAM for authorizations? My simple Provisioning-guy process won’t work on its own, because that process doesn’t push a policy to the WAM system to enable authorization decisions. Similarly, the WAM-person’s approach won’t work because the process only checks for the existence of membership, it doesn’t grant membership. So in this case if you talk to either the provisioning team or the WAM team and ask how someone gets access the answer you get sounds suspiciously like the South Park gnomes’ business plan; that is to say the answer you get is incomplete.
In order to govern access in this scenario, you need both the provisioning and WAM process (and related policies) to work in concert. The provisioning policy governs access at administration-time, and the WAM policy governs access at run-time. But how often are these policy built in a coordinated manner? Ask yourself, when’s the last time provisioning teams and WAM teams sat down and worked out policies and process together? If they do, are the teams interactions and outputs part of your identity governance process?
Why bring up such an old-school scenario? Because we are still living with this chronic pain. We have yet to figured out how to make our administrative and run-time policies act in concert. Unfortunately, these policy continue to be created, maintained, and executed in separate bell jars.
To manage access in a world where authorization decision are externalized from the application (think federated and finer-grain auth scenarios) requires that two different policies, administration and run-time, are created and maintained.In order to understand how someone truly gets access you have to understand both the administrative and run-time policies. Today there is no good automated way to built associated administrative and run-time policies – heck there isn’t even a mediocre automated way to do this.
As an industry, we are seeing the emergence of a pull-based architecture, an architecture that relies on externalized authorization management. If we do not find some ways to associate and manage the needed administrative and run-time access policies in a coordinated manner, we will continue to suffer from this chronic pain emanating back from the provisioning and WAM glory days.