Tuesday, May 12, 2009

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

8 comments:

Paul said...

I think you are making a huge assumption that entitlements management is only related to the web access layer. You seem to be purely discussing the concept of entitlement management as the next level from coarse-grained entitlements within a web application.

Whilst that is one of the applications of entitlements management, you seen to miss the point that a proper entitlements management solution can work at any tier and with any application.

For example, Oracle Entitlements Server can indeed integrate at the web application layer. However, it also has integration at the application tier, the integration tier and even the data tier. This allows you enforce a standard policy for a particular application or set of data across all tiers and channels of access consistently.

As soon as you understand this concept, then you appreciate why these are two separate products since they can address different requirements. I agree that they have complimentary capabilities but it isn't right to assume that all authorisation can or should be done within the web access management product.

Matt Flynn said...

Ian, in addition to what Paul wrote, I would also be careful not to define a solution's business value by the technology used to implement it.

For example, some Web-SSO solutions have the ability to provide fine-grained access control through the use of API calls from the web app. In that scenario, it's entitlement management (because you use the Web-SSO solution to manage fine-grained entitlements) but not XACML.

So, IMHO, we use the term 'Access Management' broadly as a category and 'Entitlement Mgt' is one capability within that category. And XACML is one way to implement Entitlement Mgt.

'Enterprise Entitlement Managment' is about finding a solution to manage access permissions across a borad range of solutions. And the solutions that most people refer to as 'web access management' are just one of the systems that an enterprise entitlement management solution would help manage.

Stephen Swann said...

I agree with Matt with everyone :-)

TAMeb, for example, is usually used to provide coarse-grained access control at the URL level, but the Authorisation Server component provides fine-grained access control right down to the EJB layer but the API allows for any application to perform authorisation requests. (In a past life, I've knocked up a dodgy desktop VB application and had it talking to a TAMeb Authorisation Server for authorisation requests.)

BTW. Consider the terms: Entitlement Management, Identity Management, Access Management, Privacy Management, Security Management. To those who don't understand what each actually means, it could seem that these are basically variations on the same theme.

It can be frustrating telling somewhere why Identity Management is not the same as Access Management (believe me, I've had too many of those conversations). Trying to fit Entitlement Management into the conversation is not something I want to do :-)

Neil Readshaw said...

One other way I have seen authorization vs entitlements characterized is by the perspective from which the access control data is viewed. 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.

Also, to correct a minor point, there was never an XACML offering for TAMeb.

Ian Yip said...

Paul,

I'm not making an assumption at all. I'm including ALL sorts of applications and systems. I didn't point this out (although I might soon) but I don't agree with the term "web access management" at all because it focuses too much on the reverse proxy component. In truth, many web access management products can do a lot more and that's my point. The word "web" in "web access management" is a red herring the industry's chosen to throw in.

Matt,

I like the way you're looking at this. After all, that's what I'm trying to say. It's all simply access management. There is no need to try to fool everyone into thinking entitlement management is a new concept that needs a new product. The reason I've thrown XACML into the mix is because in today's environments, there needs to be a standard and apparently some sort of web service capability. I agree that without XACML it would still be entitlement management, but by many definitions I would have been pulled aside for ignoring that part of so called "entitlement management".

Swannie,

Your TAM example is one of the things I'm referring to where IBM could have just tightened up the TAM product to bring it up to speed with that's required today. And yes, I don't particularly like trying to explain the difference between access and entitlement management to customers either.

Neil,

That's a pretty good way to look at it. Thanks for the clarification on the TAM and XACML thing. Will update the post. Minor point too mate. Why are you spelling like an American? :-)

Steve said...

To Paul's point that the scope of policy-driven access control is not limited to Web access layer, I think one aspect of the issue with IBM TSPM is that SOA-governance requirements were on the lengthy wish list involved in TSPM's product definition. The need to globally manage and reconcile local enforcement rules, and to integrate services registry information into policy definitions are DataPower product management concerns. On the other hand, the ability to apply attribute-based controls on application objects and containers is more of a Web access management policy requirement. There needs to be a shared abstraction layer that both (WAM, SOA/WS) feed off - that TSPM doesn't quite seem to satisfy.

Ian Yip said...

Well said Steve. I think IBM missed the mark with TSPM.

Vadim L said...

Interesting hypothesis...

I disagree with the first point and somewhat agree with the second point (although the XACML comment is highly debatable).

A WAM policy protecting an application entry point can be fine-grained or coarse-grained, depending on how much information needs to be evaluated...this could include form post data, query string data, session context data, authentication strength data, ip location data, etc.

If we assume for a second that entitlement management = authorization (not a done deal yet btw), then authorization is about fine-grained access management.

All authorization policies should be fine-grained in nature...its just a matter of how stringent security requirements are and how sophisticated one's policy engine to meet those requirements.

to summarize, I see the fine-grained vs coarse-grained discussion being about defining a security policy that meets the business need - it doesn't define the market.

And XACML is just one of many ways to implement authorization policies.