Spinning entitlements

A few of us (e.g. me, Nishant Kaushik, Matt Flynn, Paul Madsen, Ian Glazer) have been lamenting the negative effect Twitter has had on our blogging frequency. As a result, we've also had a lack of discussion via our blogs. But Twitter discussions can only go so far.

As such, my previous post about entitlement management was intended to stir the pot a little bit (which is why I posted the "equation" as a hypothesis) and also bring to the surface one of my pet peeves with how some vendors position entitlement management.

I wanted to achieve 2 things:

1. Point out what you're actually getting if you buy an entitlement management product from an access management vendor.
2. If we MUST use the term "entitlement management", we should at least have a good reason for doing so instead of using it to sell more products by re-branding an old concept.
   

I purposely focused only on the authorisation/access management side of things to serve the first part of the agenda. That is, if we look at the entitlement management products from access management vendors today, the hypothesis that entitlement management = fine-grained access management + XACML holds. In other words, that's all you are buying.

The second point required discussion so I conveniently ignored everything else that I've heard people refer to as "entitlement management". The most common example is in relation to IT Governance, Risk and Compliance (GRC), specifically identity compliance and attestation-type activities. I don't typically refer to this as "entitlement management", but others do.

These are the 2 obvious sides to the entitlement management coin, but there are others that could conceivably pop-up. For example, Eve Maler brings up the possibility that Vendor Relationship Management her ProtectServe/"relationship management" proposal could potentially be thought of as "Enterprise 2.0 entitlement management" (update: Eve clarified that she meant ProtectServe rather than VRM via the comments to this post).

It's clear that the term "entitlement management" means different things to different people. It's a bit like the spinning lady illusion (where depending on how you focus, you see it spinning in one direction while others see it spinning the opposite way). In our case, some might not think we're even looking at a lady's silhouette. I don't like things to be complex (which makes people wonder why I chose this line of work). But it's also for this reason that I don't like the term "entitlement management". It confuses the heck out of everyone!

I received a few email responses. There were also a couple of opinions on Twitter, a few more in the comments to my post (which I responded to there) and a handful of blog responses (Nishant, Ian Glazer and Dave Kearns). Some agreed, others partially and some not at all.

Before I move on, I should clear something up. Paul Toal (from Oracle) comments:

"I think you are making a huge assumption that entitlements management is only related to the web access layer".

I'm not. And that is part of the problem with calling all these access management products "web access management" products. It makes everyone assume that's all these products do. And that was part of my point; that they can do so much more. Simply calling them "web access management" products does their capabilities an injustice (although some have less fine-grained access management capabilities than others). I should be able to add a little more context when I write about my first Identity and Access Management project (as promised in my previous post) but I won't talk about this "web access management" generalisation today because we'll lose focus.

In reading through the opinions of others, I noticed one thing in general; most toed the company line, which was not unexpected:

• People from Sun more or less agreed (probably because I said I liked how they are approaching it with OpenSSO).
• People from Oracle tended to use fine-grained access management as a baseline and expanded on it to include centralisation across all platforms with a common enterprise services view on everything.
• Consultants didn't like having a new term to define something they've been doing for a long time and find it difficult to explain it to customers without confusing them.
• Those who have been around and know security but don't have as much of a vested interest in "entitlement management" like to take a more pragmatic approach in trying to segment the definitions into manageable portions that make sense while not discounting the term altogether.
  
• Some of the more sales-oriented folk who don't have to sell a so-called "entitlement management" product didn't like having to explain the term because it distracts customers. Either that or they worry about the need to "shoe-horn" their product/s into the "entitlement management" hype if that's all they hear about when doing sales calls.
  

I more or less agree with what Nishant says in his blog post, but not Oracle's strategy in having 2 separate products. Then again, Oracle Entitlements Server was brought on board via their acquisition of BEA so I can understand why they chose to keep it separate. It probably didn't make much financial sense to try to roll one product into the other. In their case, cash won out over idealism.

Ian Glazer has 4 problems with my hypothesis/definition. I'll address each here:

1. "Definitions that include a protocol are worrisome as they can overly restrict the definition" - He has a point. I should probably have said "an authorisation/access management policy standard". But in reality, my view is that it'll be XACML or some evolution of it. So if we wanted to make an academic definition, then we should probably not say "XACML". I'm not a fan of academic definitions though, otherwise I would have accepted the PhD offer from my university professor instead of joining IBM.
2. "I fear this definition is a reflection of products in the market today and not a statement on what “entitlement management” is meant to do" - Bingo! Ian Glazer's just summed up a lot of what I'm getting at. I DID define it as per what the access management vendors think it should mean. Whether this is what it should mean is up for debate.
   
3. "There is something missing from the definition – the policy enforcement point" - True, if you think the definition should include the terms: policy administration point (PAP), policy decision point (PDP) and policy enforcement point (PEP). Then again, I didn't have PAP or PDP in the hypothesis either. It comes down to whether one thinks that access management products as they exists today have PAPs, PDPs and PEPs. Even so, I personally think they should be in the finer details and not the definition. As an aside, access management products with fine-grained authorisation capabilities do have some PEPs. But PEPs are a little bit like connectors in provisioning products; one size does not fit all. There's usually some work that needs to be done to build a PEP that works for whatever system you are hooking into the access management product. The obvious exception here is the web reverse proxy component in access management products because they can assume a standard protocol is in place for web-based interactions. Of course, the web reverse proxy does coarse-grained access management (aka "web access management") by many common definitions. But now I'm just confusing the matter so I'll stop :-)
   
4. "I have a problem with the phrase “entitlement management”...enterprises do not use the phrase “entitlement management” the same way we do" - It's because the vendors have managed to confuse customers. On one hand, we have the "entitlement management" that vendors use to describe run-time authorisation (which I've been referring to as access management). On the other hand, we have vendors that talk about certain aspects of IT GRC as being "entitlement management". Based on what Ian Glazer is saying, the companies he's talked to see it more from an IT GRC (or operational) perspective.
   

Ian Glazer goes on to say:

"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."

Yeah, tell me about it. Unfortunately, this is what we have today. It's an overloaded term which has already lead to confusion. At this point however, I'm unsure what Ian Glazer's position on the whole matter is. On one hand, he's helping round out the entitlement management definition from an access management (or run-time authorisation as he puts it) standpoint but on the other hand alluding to the fact that including this aspect in the overall definition can lead to confusion.

Dave Kearns doesn't agree with the hypothesis either. He also says he doesn't quite agree with Ian Glazer but I think he's actually disagreeing with Burton Group's perception of how enterprises define entitlement management. As I said, I'm not quite sure how Burton Group wants to define it. No matter. At least it prompted an opinion from Dave. But he goes on to say that he thinks entitlements should be tied to roles, not individuals:

"Differentiate entitlement management from access management, also (else, why use both terms?). Individuals get access, roles/groups get entitlements. Access is granted to resources (hardware, applications, services, etc.) while entitlements specify what a particular role/group can do with or within that resource."

If I were to simplify this, I would interpret it as saying access and entitlements are more or less the same thing but with intricate, important differences in terms of how you look at it. You use one term for individuals and the other term for roles. I do agree with Dave from a conceptual point of view, but I don't see the need to differentiate individuals and roles here because we're getting very close to implementation specifics if we do and are in danger of adding to the confusion.

Neil Readshaw, an ex-colleague of mine from IBM and a worldwide authority on Tivoli Security products says (via a comment in response to my previous post):

"I try to talk about authorization when taking a resource centric view (e.g. who can do something), and entitlements for a user centric view (e.g. what can this user do). In the end, it may be the same data making both of those determinations."

Neil and Dave are talking about pretty much the same thing but I prefer Neil's version because it takes a higher-level approach and avoids specifics like mappings between individuals, roles and resources. Neil's statement about "the same data making both of those determinations" however, begs the question: why do we need a separate product to do entitlement management?

I did find this statement by Ian Glazer interesting though:

"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 automatic assumption would be to blame Burton Group for this mess. But if you think about it, it's not really their fault. It's the fault of all the vendors for jumping on the bandwagon and hyping it to the point it's now out of control and we find ourselves having to come to terms with some sort of definition so we can see through the entitlement fog.

Burton Group's views seem to have evolved and the vendors are stuck with a definition a couple of years old. My objection all along has been to vendors jumping on the bandwagon and trying to convince everyone that it's such a "must have", new concept to the point where customers need to buy their new "entitlement management" product before understanding what it really means. Worse still, a few went out and built brand new products and slapped the name "entitlement manager" (or a variant) on it. Would it not have made more sense to allow their access management products to evolve naturally with business needs and keep calling them "access management solutions"? Why did they have to go and confuse the matter and in the process force customers to support separate data and policy stores for products with a lot of overlapping capabilities?

If we must have the term "entitlement management" hanging around in the lingo, we need to re-adjust our understanding of what it means. Once this is done, perhaps the vendors will rename/re-think their "entitlement management" products or roll them into their access management offerings like they should have done in the first place. Analysts like Ian Glazer should be able to help the market define this because they talk to companies about what they are actually doing. My objection isn't with the industry as a whole for talking about entitlement management. It's out in the wild now and nothing any of us can do will put the entitlement genie back in the bottle. But we shouldn't be re-branding an old concept just to sell more products.

If this discussion doesn't get us closer to a good definition, I'd like at least one thing to happen. If you are looking at an entitlement management product, please take a step back to understand what it is you actually want. You might already have the tools to do it. If not, make sure you're buying the right tool for the right reason. Not just because the vendor tells you it's their "entitlement management" product and you MUST have it because you are looking at user entitlements in your environment.

The entitlement and access management equation

Hopefully I'm not having a "mad-scientist moment"...

Hypothesis:
Web access management = Coarse-grained access management
Entitlement management = Fine-grained access management + XACML

Argument:
I've always poo poo-ed the whole notion of entitlement management and even blogged about it some time ago (Daniel Raskin from Sun had similar thoughts). It's not because I don't think it's necessary; quite the contrary.

Good access management is crucial within any enterprise security architecture. It doesn't need to be the first thing you implement, but it should be pretty darned high on the list. It saves time and money in the long run and makes things so much easier to design, build and manage. Not to mention when the audit and compliance people come knocking, a lot of the information is available from a central location (I didn't say "all the information" because it's wishful thinking that any organisation can get every system's access controls centrally managed).

Notice something? I said access management, because that's all entitlement management really is; fine-grained access management. The main reason I've never particularly been taken by the whole notion of entitlement management was because I didn't agree with the industry's need to tag it as such. As far as I was concerned, it was just access management (or authorisation as some prefer to say). There was no need for a new name because we've all been doing access control for a long time right? Apparently not. The marketing machines started spinning not so long ago and all of a sudden, it's "New School Identity Management" (note: you may have to register to read the article).

The marketing people would have us believe that before entitlement management products came along, all the industry was capable of doing was web access management. That is, URL-level access controls. And if we needed to have finer-grained access controls, we would just throw our hands up and say "nup, product doesn't do that and we'll have to write our own or just ignore it". As Guy Kawasaki would say, this is BULL-SHIITAKE! Or perhaps I joined the Identity and Access Management (IAM) world with rose-coloured glasses.

Early on in my stint at IBM, I worked for the Security and Privacy Services team. My very first Identity and Access Management (IAM) project was actually entitlement management focused with some aspects around web access management. At the time, the term "entitlement management" didn't exist the way it does today. As far as we were concerned, we were implementing access management; both coarse and fine-grained. And it was on this project that I first got my hands VERY dirty with Tivoli Access Manager for e-business (TAM) and Tivoli Directory Server (TDS). I'll talk more about this in a follow-up blog post or this will get too long and you'll all fall asleep.

I've had a few more opportunities to work with TAM (and all the other IBM Tivoli Security products) and it is because of my various experiences with the products that I haven't stopped wondering why companies like IBM bothered to build a completely brand new product to handle entitlement management (in IBM's case they now have Tivoli Security Policy Manager). TAM does have a few potential issues when it comes to entitlement management as we know it today. For example:

1. If you need to model contextual policies that rely on user attributes and getting your hands dirty scares you, then you'll find it a little bit challenging.
2. It doesn't have standard support for eXtensible Access Control Markup Language (XACML) out of the box.
3. It doesn't have a nice, standardised web services layer for other applications to integrate with (it does however, have APIs but these aren't typically what we would call "services").
   

That said, TAM did have a XACML toolkit which (update: Neil Readshaw, one of my ex-colleagues at IBM and a worldwide authority on TAM assures me there was never any XACML support in TAM whatsoever. I must have been drinking too much of the kool-aid when I worked for IBM Tivoli) I'm sure product management and development could have rolled XACML support into the core product. They could also have very easily opened up the console (or even built a whole new one that was easier to use) to allow for easier administration of contextual access policies and even expanded on the policy model to do more fancy things (alternatively you can use a provisioning product to fill in the gaps). As for web services, that isn't too difficult to build into TAM. They built a whole federated identity management product on top of it. Why not an entitlement management one?

I've seen Tivoli Security Policy Manager (TSPM) in action and it doesn't add very much on top of what TAM already does (and has been doing for years). And now, customers have to manage 2 separate policy stores for 2 products that do very similar things! You heard me right; TAM and TSPM have different policy stores and management interfaces. I realise I'm picking on IBM yet again, but this is true of many vendors that have separate web access management and entitlement management products.

So why the sudden emergence of entitlement management when I insist it's been there all along? If you followed the link back to my earlier rants about entitlement management, you may have noticed I had a rather involved public conversation with Securent's (now owned by Cisco) CEO Rajiv Gupta. Upon reading the discussion again, we seemed to be debating entitlement management vs fine-grained authorisation based on different definitions, assumptions and agendas.

This suggests that what fine-grained authorisation lacked was a standard way to define everything; enter XACML. If we could talk about everything using common terms, an understanding of where everything fit and what a policy looks like, then we might get somewhere. The same goes for systems: there needed to be a way for them to leverage authorisation services in a standarised way. So I put forward that entitlement management is simply fine-grained authorisation + XACML. Standardisation and interoperability were the missing ingredients in taking fine-grained authorisation mainstream. Perhaps another ingredient was that many companies weren't ready to worry about fine-grained authorisation yet as they were still busy with provisioning and coarse-grained authorisation (i.e. web access management).

I'll finish with the following points:

1. If you can't tell, I like TAM (but I'm biased because I cut my IAM teeth using it).
   
2. If you have a web access management product, make an effort to sit down and evaluate whether you REALLY need an entitlement management product. If you also have a provisioning product on top of your web access management product, then you REALLY need to think about whether you REALLY need an entitlement management product. Is XACML support a good enough reason to buy a whole new product? Do you really need XACML at this stage of your project? Can you talk the vendor into building XACML support into their web access management product?
   
3. I like Sun's approach of rolling fine-grained access control/entitlement management capabilities into their core web access management product (note: unfortunately, I have a feeling Oracle will throw OpenSSO aside in favour of their existing products - which I should point out are 2 separate products).