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 [...]]]> 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.

Finally, I have a problem with the phrase “entitlement management” (just ask my co-workers). As I have blogged about before, Kevin and I have been in the midst of a large research project focusing on role management. One of the things we have learned from this project is that enterprises do not use the phrase “entitlement management” the same way we do.

A bit of history – three or so years ago Burton Group, at a Catalyst, introduced the phrase “entitlement management” to include the run-time authorization decision process that most of the industry referred to as “fine-grained authorization.” At the time, this seemed about right. Flash forward to this year and our latest research and we have learned that our definition was too narrow.

The enterprises that we talked to use “entitlement management” to mean:
·      The gathering of entitlements from target systems (for example, collecting all the AD groups or TopSecret resource codes)
·      Reviewing these entitlements to see if they are still valid
·      Reviewing the assignment of these entitlements to individuals to see if the assignments are appropriate
·      Removing and cleaning up excessive or outdated entitlements
More often than not, we found that our customers used “entitlement management” as a precursor to access certification processes.

Using a single term (“entitlement management”) to span both the run-time authorization decisions as well as the necessary legwork of gathering, interpreting, and cleansing entitlements can lead to confusion. The way enterprise customers currently use “entitlement management” works well to describe how legwork is vital to the success of other identity projects.  (I’ll be working on a report this quarter that delves deeper into this.)

I am all for a broader conversation on fine-grained authZ versus entitlement management. And as Ian Yip has pointed out on twitter, identity blog conversations have dropped off a bit and I’d love to stoke the fire a bit.  But we can’t have meaningful conversations without shared definitions. So what’s your take? What do you mean when you say “fine-grained authorization” and “entitlement management?”

(Cross-posted from Burton Group’s Identity blog.)

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 [...]]]>

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. 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federate account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.

This step is the [...]]]> 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.  ;-)

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.

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization.  Got it.

James has provided me more to work with…

Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.

Ah, so identity consolidation is centralized authorization.  Got it.

I am making the assumption here that when James says user store he means authorization store.  (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.)  I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides.  The application would consume this authorization data, at runtime, and act accordingly.  Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store.  Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.

Identity management says that I should go create a strategy around provisioning of identity and leverage tools such as Sun’s IDM, Thor, etc where I still fundamentally allow enterprise applications to have their own user stores and takes me down the path of building lots of connectors… [snip]  I am of the belief that identity management (provisioning) propagates and encourages an otherwise bad architecture.

I look at user provisioning as dealing with the reality (and foreseeable future) of the enterprise landscape.  That landscape involves lots of user and authorization stores.  For reasons I discuss below, that is not going to change any time soon.  It is better to provide flexible, short time-to-value solutions, as identity management does, that address the reality of today than to wait for the ideal enterprise landscape to arrive at its glacial speed.

I disagree with James’ assertion that user provisioning requires the construction of connectors.  The connector wars of the provisioning world are over.  Connecting to systems like a complex bespoke application or RACF or SAP has become a science, not an art.  On the whole, provisioning doesn’t require connector construction; it requires configuration.  Each provisioning vendor worth their salt has a way of quickly connecting to “unknown” systems that don’t require core engineering efforts.

The one thing that I would also love insight into is how to get vendors who still insist on having their own user stores (e.g. Documentum, Alfresco, etc) to see the error of their ways and to take quick steps towards remedying them.

I think you’ll find the reason the vendors give on maintaining their own user and authorization stores is much the same reason why they have yet to adopt Service Provisioning Markup Language in a meaningful way.  There is nothing in it for them.  Nada.  The only vendors who might stand to gain (and thus adopt) centralized authorization are mega-vendors like IBM who have dozens upon dozens of applications.  For these vendors, producing a common auth store with the requisite halo of tooling becomes a path to customer lock-in.  “Ms. Customer, you can use AuthStore 5.0 to manage all of the authorizations for all of our products.  And here is AuthManage 6.0 to help you do just that.”  And if the customer ports their bespoke applications to the common auth store, the vendor gets big-time lock-in.  Want to get rid of XYZ Vendor?  You’ll have to reincorporate authorization stores into your applications. I have to imagine externalizing an auth store for a homegrown application would be painful, undoing that work even more so.

Stepping back to what I originally wrote about: no amount of centralized user and authorization management will make up for a lack of strong organizational and business process understanding coupled with appropriately defined controls.  That is the fuel for identity management and, frankly, identity consolidation as well.

 Before I respond [...]]]> James recently picked up on my Identity leprosy or identity zombies post and writes:

Ian believes that identity needs brains but falls into the trap of thinking about identity solely from the perspective of provisioning and while avoiding runtime aspects. I wonder if he would blog on why enterprises should consider identity consolidation over identity management? 

 Before I respond I’d like to get some clarity.  James, give me a more to work with and I’ll happily write more.  Help me understand that which you are contrasting between “identity consolidation” and “identity management.”  Help me understand how provisioning doesn’t have runtime implications. 

We talk about Identity 2.0 in the context of Web services and the evolution of digital identity but our infrastructure, enterprise identity “stuff” is decrepit and falling apart. I have visions of identity leprosy with this bit and that bit simply [...]]]> Jackson, in discussing the demise retrenchment of HP’s identity business, had this little gem:

We talk about Identity 2.0 in the context of Web services and the evolution of digital identity but our infrastructure, enterprise identity “stuff” is decrepit and falling apart. I have visions of identity leprosy with this bit and that bit simply falling off because it was never built with Web services in mind.

Bits falling of, eh? I’ve never heard of someone losing their core directory services because someone forgot to add XACML support. I’ve also never heard off someone loosing an ear because their provisioning system didn’t support SPML v2. Enterprise identity “stuff” is more like a zombie. It lurks in the dark corners of your enterprise. It staggers out at you at inopportune moments. Two other aspects of this ridiculous image that are valid:

1. The identity zombie is incredibly hard to kill.
2. The identity zombie needs BRAINS!

“They stab with their steely knives…” Once deployed, even in rudimentary forms, enterprise identity systems are amazing difficult to uproot, to kill. Homegrown systems are notoriously tough to maintain as well as replace. Even worse were those early attempts at vendor provided solutions. Before IBM/Tivoli bought Access360, it had Tivoli User Administrator. TUA… one of the banes of my existence. The thing wouldn’t die. The customers who got it running were actually in love the rotting smelly thing. They kept it on a steady diet of scripts (BRAINS!) that served as connector definitions and entitlements all rolled into one. It just ran and ran and ran. From what I heard, early BMC Control/SA customers are much the same.

Think this problem is limit to the “old timers” in the identity market. Nope. Good luck replacing that SiteMinder deployment. Enjoy uprooting your original iPlanet directory implementation.

BRAINS!

We all know zombies feed on brains. Common knowledge. Let’s consider for a sec that the enterprise identity “stuff” that Jackson refers to is a friendly, but slightly misguided, zombie. The rising aspects of the identity market are the brains that is so badly craves: enterprise role management, entitlement management, fine grained access control, etc. Feed our enterprise identity zombie with a healthy does of policy that has business-readable language as to role of the person and their subsequent entitlements and you’ll have an enterprise-class, unkillable (in the good way), identity infrastructure.

Further, you do not have venture into the newer territories of identity land to feed your identity zombie. Enterprise identity implementations have sufficiently progressed to the point that your more mature services providers can feed your zombie all the brains it needs based on their own experience, methodologies, and techniques: no emerging technologies needed.

Do enterprise identity technologies need a bit of a refresh? Sure. But that doesn’t mean they need a complete rip and replace with user-centric or other newer identity “stuff.” Absolutely not. What it does mean is that we are seeing a rise in the value of identity brains, entitlement and access management in business and organizational terms.