I just came home from San Diego, where I was at Gartner’s Identity and Access Management conference.
A good event, actually. Lots of smart people in one place, all passionate about identity and access management and sharing their real-world experiences.
One session that really struck a chord for me was Ian Glazer’s talk titled “Developing a Business-Centric Identity and Access Management Strategy.” This may seem self-serving, but it struck a chord because a lot of what he was saying was so closely aligned with what we’ve been doing here at Hitachi ID for some time.
For example, he proposes an incremental approach to identity management projects, which we also recommend. I think that’s pretty widely accepted these days. “Boil the ocean” never worked for anyone, in IT or other disciplines.
More importantly, he offers a nice, practical way to help organizations figure out how to break down their monolithic identity management objectives into bite-sized pieces. Basically get your stake-holders to sit down together and fill in a worksheet with the following columns:
- Source of truth
- Opportunity for life cycle automation
- Life cycle event
- Target system:
- Fulfillment volume
This is very similar to what we already do in workshops that we hold with customers before starting an engagement. Our terminology is slightly different, but basically it boils down to:
- User community (e.g., US employees or EU contractors, etc.
- Data source (e.g., HR, contractor database, manager input, etc.
- Data quality and timeliness (e.g., is HR providing data early enough to trigger automation?
- Change type (e.g., hire, move, fire, etc.)
- Volume (e.g., how often does this change happen?
- Application (e.g., where does the organization want to create, modify or delete access?
- Impact (e.g., how important is it to get these changes made quickly?
Do you see the similarity? It’s almost identical! Gotta love it when different practitioners arrive at the same solution.
We work with customers to collect this information and prioritize. Ian structures this stuff in a table and each row is a potential deliverable, organized into a priority sequence. Nice and clear!
But there’s more! Ian was promoting the value of an “entitlement catalog.” I’ve been convinced for some time that it’s important to assign human-legible descriptions, help links and meta data to groups, accounts, roles and other resources assigned to users. The list of these objects and their meta data are exactly Ian’s entitlement catalog.
Enough similarity? No! Ian also gives a nice and clear model of manual vs. automatic processes. He structures it as follows:
- Lifecycle Events
- Access Policy Management
- Identity repository
- Entitlement catalog
This maps 1:1 to our own terminology:
- Requests portal (a.k.a. manual input of lifecycle events).
- Automatic administration engine (a.k.a. automatic input of lifecycle events from an HR feed or similar).
- Approvals workflow (a.k.a. manual access policy).
- SoD and other automated policy checks (a.k.a. automatic access policy).
- Transaction manager and connectors (a.k.a. automatic fulfillment).
- Implementers workflow (a.k.a. manual fulfillment).
- Profile attributes (a.k.a. identity repository).
- Resource attributes (a.k.a. entitlement catalog).
Man. A love-fest with Ian Glazer?
Well, that would be just a bit too weird, so I have to disagree with him on at least one thing!
Ian suggests that “Access Governance” should be decoupled from “Identity Administration.”
I agree with the need for almost all the functions in both of these buckets, but these two sets of features share so much data (remember the identity repository and entitlement catalog? policy stores? change history?). Whenever two products share a ton of data the natural question to ask is: “are they really two products, or just multiple features in the same product?” I think these features should actually live in a single product for just this reason. Plus customers expect connectors with their “governance” user interface and portal. Customers expect a usable request portal, approvals process and access certification with their connectors. I think customer expectations are reasonable.
That’s why our Identity Manager includes:
- Auto-discovery of identity and entitlement data on the applications where it already exists.
- Connectors to create, modify and delete users and entitlements.
- Automation to create workflow requests as a consequence of detected changes.
- A web portal for users to access one-anothers’ profiles and submit workflow requests interactively.
- Policy engines for things like SoD checks and approvals routing.
- Roles for simplified entitlement definitions.
- Workflow processes to invite human beings to implement approved changes.
- Workflow processes and screens to invite human beings to review and certify or remediate entitlements.
- Reports and dashboards to monitor all of that.
How is this different from Ian’s model? It’s all in a single product, with a single back-end database, a single UI and a uniform set of processes. I think the market will follow us in this integrated direction. The decoupling between “access governance” and “user provisioning” should be conceptual, not technical.