Nailing Down the Definition of “Entitlement Management”

Ian Yip’s take on access management versus entitlement management can be partially summed up with this equation:

Entitlement management is simply fine-grained authorisation + XACML

I have four problems with this.

First, definitions that include a protocol are worrisome as they can overly restrict the definition. For example, if I defined federation as authentication via SAML, people would quickly point out that authentication via WS-Fed was just as viable as a definition. So in terms of an industry conversation, we need to make sure that our terms are not too narrow.

Second, I fear that this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do.  Yes, most of today’s products can use XACML. Yes, they facilitate authorization decisions based on a wider context. But who’s to say that these products, and the market as a whole, have reached their final state? Along these lines, I wonder if externalized authorization stores are a required part of an “entitlement management” solution?

Third, there is something missing from the definition – the policy enforcement point. A fine-grained authorization engine provides a policy decision point, but that still leaves the need for an enforcement point. This holds true whether an application has externalized its authorization decisions or not.

Will the “real” federated provisioning please stand up?

Nishant has commented on my post about federated provisioning.  He has provided two different examples of federated provisioning.  One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning.  In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

 

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher.  In this case, the enterprise and its service provider have a federation in place.  Using SAML-based authentication, a new user attempts to access the service provider’s service.  The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficult in this scenario as he ties the federation service to a provisioning service.  Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider.  And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system. 

 

Thinking about Matt’s Simple Question: Correlating accounts and people

Matt Hamlin, over at Sun, mentioned a conversation we had last week about a topic in identity management which doesn’t usually get a lot of airtime: the correlation of accounts to people.  The exercise is the first step in answering Matt’s simple question of “Who has access to what?”  Matt writes:

This step is the foundation for Access Certification, Role Mining, Entitlements Management, Policy Evaluation, Identity Auditing, and numerous other custom services developed by our customers.

There were two major omissions in his list: password management and user provisioning.  The reality is the correlating of accounts to people is a requirement for all identity management exercises.  This correlation isn’t glamorous work and isn’t a one time affair.  None the less, it is crucial “Identity Gold” for identity management projects, but also as the foundation for risk mitigation exercises as well.

Here’s a tip to enterprises out there – ask your software vendors and deployment teams what capabilities they have to help facilitate this correlation.  Ask early and before you start down the path of an identity project.  Make it an on-going process governed by your overall identity management program.

I’ll be touching on this a bit in an upcoming Telebriefing I am doing.  On October 1st and 2nd, I’ll be giving a sneak peak of my research on access certification and will cover this and other topics.  If you are a Burton Group subscriber, you should check it out.  If you aren’t a BG customer, you should become one.  ;-)

No, I didn’t steal the shirt; I actually do work for Burton Group

I have interacted, both socially and professionally, with Burton Group in a variety of ways over many years.  The quality of people, their integrity, and the quality of their work have always impressed me.  In short, Burton Group is the kind of place I want to work for and the people are the kind of eccentric, entertaining people that I love being around.

After a few years in the making, I have joined Burton Group as a senior analyst on the Identity and Privacy Strategies team.  The first day at a new job is always a little gut churning.  When that first day is the first day of the Catalyst conference it gets even more interesting.

Today I found myself on stage with the rest of the team during the Identity Management market overview presentation.  Stoically silent, I scanned the room for friends in the industry.  Needless to say there were more than a few very surprised people.

As my first real act as an analyst I recorded an introductory podcast – Not bad as an intro.  Obviously, there will be more to come as I take on my research projects.  Stay tuned!

Burton Group Catalyst 2008 Roll Call

It is that time of year again: Catalyst.  I know that Nishant and two Marks (Dixon and MacAuley) are headed to San Diego.  Who else is going?

This is my fifth or sixth Catalyst conference and will be a bit different for me.  I’ll explain more next week.

See you there.