F*** it, I'm lighting 100 candles - Entitlement Management 2012

Photo credit: Alessandro Silipo

One of the most widely read series of posts on my blog relate to entitlement management (part 1, part 2). In fact, do a search on Google for "entitlement management" and part 1 appears on the first page of search results (albeit below the fold). Don't read them yet. You'll get tired and won't come back to continue reading this :-)

I wrote those posts over 2 years ago to stir the pot. They served their purpose and garnered some great discussion with a few luminaries in this space (including esteemed analysts from Gartner and Forrester).

At the time, I argued that the term "entitlement management" was typically used to refer to fine-grained access management or real-time, attribute-based, authorisation enforcement (e.g. as per the products offered by IBM, Oracle, Axiomatics and BiTKOO (now part of Quest Software)). But on the flip side, I did acknowledge (in part 2) that there were other ways to define it:

1. The processes and solutions around gathering, interpreting, and cleansing entitlements.
2. User-managed (or user-centric) entitlement management.

Point number 2 is a topic best left for another day, especially as it involves discussions around online services (see UMA for more info).

The first point however, is what we now commonly refer to as access governance (e.g. SailPoint, Aveksa). Some use "identity intelligence" (thanks to the analysts), but in my opinion, identity intelligence is a broader term that also includes data analytics and Security Information and Event Management (SIEM). However, "manage user entitlements" is another commonly used term in access governance discussions. In fact, it is used so often that I'm starting to find when anyone talks about entitlement management, more often than not, they mean managing user entitlements for access governance purposes.

Back in 2009 (when I wrote the posts referenced above), I was convinced that real-time, attribute-based, fine-grained authorisation enforcement would take off. IBM and Oracle certainly thought so too. I have yet to come across a security architect who doesn't think it's a good idea. I still think it's a great idea. But in the world of Information Security, just because something is a good idea does not make it compelling. Compelling; aye, there's the rub. If I had to distil security spending decisions down to one word, it would be: "compelling". In a recent presentation I gave, I said:

"Sexy technology doesn't sell security. Interesting technology doesn't sell security. But give someone a compelling reason, and they'll buy a security solution."

That statement sums up why entitlement management has evolved to be more about access governance than fine-grained access management.

Trying to sell someone on the fine-grained access management story is an almost impossible, thankless task. If any of you have ever had to sell a provisioning solution without out-of-the-box adapters (or agents, or drivers, depending on which vendor's solution you are familiar with), multiply that pain by a factor of 100 and you might start to get close to the challenges faced with selling a fine-grained access management solution. It's like saying: "please buy our power station, but you have to figure out how to build the light bulbs yourself after ripping out the ceiling to install wires and by the way, there are 1000 ways you can build light bulbs using 1000 different sockets into the wiring with each bulb running at a different wattage".

Access governance initiatives on the other hand, are almost always driven by regulatory compliance requirements. This makes access governance initiatives compelling. It is also why SailPoint and Aveksa are doing so well.

To be successful at selling fine-grained access management solutions, you have to go to customers with a pre-built set of light bulbs and only focus on the ones with wiring compatible with your set of light bulbs. It's why BiTKOO does well in Microsoft SharePoint environments.

Essentially, access governance solutions are much less intrusive, much easier to integrate and are supported by compelling reasons to buy.

As reliant as we are on electricity nowadays, if we were told we had to rip our ceiling out, install wiring ourselves and build our own light bulbs, most of us would say:

"F@#$ it, I'm lighting 100 candles."

My first identity and access management project

In a previous post (which I subsequently followed up with another), I mentioned the first Identity and Access Management (IAM) project I worked on. I also said I'd follow that post up with more details about the project I mentioned. It's been some time since I said that, but I've finally gotten around to it.

My very first IAM project was an extremely large one. It was for one of the larger Australian federal government agencies and I can't give specifics (or they'll hunt me down) so forgive me if I'm vague in certain parts.

They needed to re-engineer a core, critical business process from end-to-end. This meant a brand new system needed to be built and it ended up taking years. I personally spent almost 2 years early in my IBM career working on this monster as a consultant in the Security and Privacy practice and when I finished serving my time there (reference to prison completely intentional), they were still rolling out other functionality.

My job was done however, because we had finished laying down the whole security framework and it was working in production. The security system was actually very well architected thanks to the fact that it was designed by a very senior, very experienced, absolutely world class enterprise security architect (hi BP, I'm referring to you if you're reading this - probably not though so one of you other IBMers will have to tell him I said hi). This was actually the key. We could have slotted any equivalent product into the architecture and it would have served its purpose. Of course, being strategically aligned with IBM Tivoli meant this was what we used.

The project used a bunch of IBM software: WebSphere Application Server, MQ Series, DB2, some other IBM software to support EDI transactions (can't remember the names anymore) and of course IBM Tivoli Security software (specifically Tivoli Access Manager for e-business and Tivoli Directory Server). We even had full blown PKI software (from another vendor) to support signing of messages (for authentication purposes) and encryption. At the core of this mish-mash of software wrapped with services (provided by a consortium that was not limited to IBM alone) was Tivoli Access Manager for e-business (TAMeb). And what was its primary use? Fine-grained access management or as some of the market likes to call it today; entitlement management.

That's right, I was responsible for implementing fine-grained access/entitlement management in very first IAM project but I didn't know it at the time. Absolutely everything had to ask TAMeb before it could do anything. Want to show a button on a page? Ask TAMeb. Want to show a field on a page? Ask TAMeb. Want to allow someone to process a particular transaction? Ask TAMeb. Can this application send this message to this other application where the message is marked as secret and does it need to be encrypted as well? Ask TAMeb. No application security decisions were made without first making an authorisation call to TAMeb. None of this stuff involved web access management! Sure, we had to implement the web access management aspects too, but this was not the focus. We put in the web access management bits because it was mandated by the security architecture. But this was by no means a web access management project.

From an ease of development, time, manageability and subsequently cost standpoint, having all access control decisions managed centrally made perfect sense. I'm pretty sure everyone on that project would agree with me on this point. Here are a few reasons why they liked having a central access management point:

• All teams could adhere to the same interface contracts when it came to authentication and authorisation. This also meant that if a development team couldn't get a security component working and everyone else could, it was their fault and usually could get it fixed fairly quickly because others knew how to do it properly.
• No one had to write their own security sub-system because it was already sitting there waiting to be used and it worked extremely well. This meant they could spend time worrying about the more interesting things like business logic. I have yet to find a developer who likes writing security code (unless they are building a security product and even then it's debatable whether they actually like what they are doing) because it's simply a hurdle to getting the "real work" done.
• Teams could re-use existing policies if required because they were mostly modelled on a business requirement.
• No need to worry about policy modelling or management of security policies.
• If a policy changed, it would be reflected across all systems. Without a central store, they would each need to worry about how to synchronise their policies so that there weren't any back doors to exploit. This alone is a whole sub-project on its own.
• Security within each system was distilled down to a single statement: "Ask TAMeb". Compare this with having to worry about designing and building a security sub-system, designing and building a way to model identities, roles, policies, resources within the sub-system, designing and building a management layer on top of the sub-system and then worrying about how to ask the sub-system to make decisions from the main application. I'm talking best case scenario here of course because quite often, development teams simply use configuration files which are completely unmanageable (if you've ever written a Java Enterprise application and played with crappy deployment descriptors, you know what I mean). And if you understand the implications of using config files, you'll know that each time a security change is made you have to restart the application (which is going to screw with your SLAs) unless your vendor has some fancy way of dynamically updating in-memory application configuration settings. Oh, I haven't yet thought about how to synchronise security policies with the other systems floating around. Manually you say? Or use a provisioning product? Yeah it's possible. But it also means a heck of a lot more design and analysis work (in the case of the provisioning product). If you want to do it all manually, you can expect to have very frequent security incidents and lots of follow-up meetings with management to explain why it happened.
  

One of the biggest challenges was the huge number of transactions (and as a result, access control decisions) passing through the system due to the sheer size of the project. And to the credit of TAMeb, it scaled well and did the job. Of course, we had to do proper capacity planning and implemented multiple enforcement and decision points (PEPs and PDPs in the XACML world). And the Policy Administration Point (PAP)? This was a combination of the TAM administration console and an application we had to build to perform "identity management". Why did we have to build this? Because IBM hadn't acquired Access360 yet (which became Tivoli Identity Manager) and the existing IBM provisioning product was a piece of crap called Tivoli Identity Director which still relied on the Tivoli Framework (those with experience playing with the old framework know it's EXTREMELY painful).

I should explain why we had to build an "identity management" component on top of TAM. One major criticism of TAM when it comes to fine-grained access management is that it's not very good when you need to add a bit of context that relies on user attributes because:

1. The admin console doesn't give you access to them (last time I checked). To play around with user attributes, you either need to access the LDAP directly or use a provisioning product like Tivoli Identity Manager.
2. Contextual access control decisions based on user attributes are also not the easiest to model without a provisioning product to help. In short, you need to do it based on dynamic role memberships and have policies on resources (or entitlements) tied to these roles. Provisioning products can do this (cater for dynamic roles based on user attributes) out of the box and provision the required changes to the access management product in near real time.

In other words, we had to build the "identity management" piece to allow for contextual access control decisions based on user attributes. Nowadays of course, you can just use your favourite provisioning product.

The glaring omission from the picture is of course XACML. It wasn't even part of the IAM vocabulary at the time and the lack of XACML support in the project makes it very difficult for the government agency to swap TAMeb out of the picture (which IBM definitely isn't complaining about). But I'm guessing it's not a big deal for them because they spent a few million shed-loads worth of tax-payer's dollars to build this system and it works as designed. They're not about to replace the critical security component that makes all the decisions!

The motivation behind my occasional rants about the term "entitlement management" and how it's all too often used as a marketing gimmick to sell more products stems from my time on this project.

Broken record time: call your vendor out if they're blatantly repackaging fine-grained access management as "shiny-new-entitlement-management". If it's more along the lines of what the Burton Group thinks it should mean, we might start to get somewhere. It's still a moving target however, so I'm sure the definition will expand and evolve, especially with all this Cloud crap floating around.

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

Part 2 of my conversation with Amit Jasuja from Oracle

I mentioned yesterday that I spoke with Amit Jasuja, Oracle's Vice President of Development for their Identity Management Product Suite. This is the follow up post to part 1, which focused on Oracle Adaptive Access Manager (OAAM). In this post, I'll cover some of the other things we discussed.

It's probably a good idea to point out that we discussed some roadmap items and even though Amit didn't remind me that items on a roadmap are not guarantees that functionality will make it into the planned release, I'll do Oracle the favour of mentioning it on their behalf. I used to have to do this all the time so I'm aware of the drill :-)

Apart from discussing OAAM, I revisited some of the questions I asked Oracle President Charles Phillips when I met him earlier this year (because Charles didn't really answer them completely) and Amit obliged.

Essentially, part of the strategy for Oracle's overall software stack (particularly Fusion Middleware) is to have everything be "hot pluggable" with their Identity Management suite. But let me take a step back for a moment. Like many other large vendors out there, Oracle's been pushing an open strategy around Service-Oriented Architectures (SOA) and the fact that all their products will eventually support the ability to leverage (and underpin) an enterprise service bus (or whatever buzzword you feel like using). One of the main benefits in doing so is to allow for a vendor agnostic architecture where organisations aren't "locked in" to specific products (note that the industry is a long way from this being a reality despite all the hype). There are other benefits but that's a topic for another day.

The organisations arguably making the most noise around SOA are IBM and Oracle. But Oracle is making more noise (and it seems progress) around the notion of Enterprise Identity Services (Nishant Kaushik in particular seems to be spending lots of time on this) and Amit was quick to point out that the Identity Management group will be keeping with the strategy of openness while being mindful of having to show the value Oracle's products can provide over their competitors. In short, most of Oracle's software will eventually be built to support the use of SOA-like interfaces thus allowing for interoperability with competitive solutions (assuming the likes of IBM, CA, Sun and Novell build products that support the relevant standards for the relevant use cases). It will then be up to Oracle to convince organisations that even though they could use a competitor's product, Oracle's Identity and Access Management suite is the best option because of additional benefits. Amit mentioned some examples like certified support for the Identity Governance Framework (which I should point out was originally an Oracle initiative but has since been submitted to the Liberty Alliance to carry forward) and perhaps things like "quick start" initiatives with pre-built policies for use with Oracle software.

It's great to see Oracle's strategy is to make all their software "play nice together" while being open at the same time. In reality however, the sales teams will sell whatever combination of products that will fit into a customer's budget. If they have to drop products out of the solution proposal to bring it under budget, they will. It's just how the sales teams work, especially if their numbers aren't 100% tied in to Oracle Identity and Access Management software sales :-)

We also briefly touched on various pieces of the Identity and Access Management suite being "pre-baked" into other Oracle software products (e.g. there's a lot of work being done to embed Oracle Virtual Directory within other products) before moving on to exploring Oracle's relatively new Entitlements Server (OES), itself a prime candidate for being embedded within other products. I didn't want to focus on functionality because I already knew about it at a high level. I was more interested in where Oracle's headed with the product from a strategic standpoint.

The obvious direction is to have OES be the fine-grained authorisation engine for just about everything, but Oracle's software stack is HUGE. In other words, it's not an easy task (even if they go with the SOA approach) and I don't think it's going to happen very quickly. Knowing this, I shifted the focus purely to the Identity and Access Management products and their use of OES to externalise authorisation. The answer: yes, but not yet. I used Oracle Identity Manager (OIM) as an example and Amit told me that the plan is to allow for the externalisation of OIM authorisation policies to OES in the next release (e.g. delegated administration settings). He did note that OIM can already provision to OES out of the box (I would have been VERY surprised if that wasn't the case).

Finally, we moved on to speaking briefly about Governance, Risk and Compliance (GRC) that controversial "catch all" three letter acronym. I wanted to know Oracle's plans around identity-centric GRC. If you aren't familiar with the whole GRC thing, I've written about it in the past so have a quick read and then come back.

As it stands today, Oracle's GRC product is much more focused on the financial and enterprise governance (and compliance) aspects and is hooked into their Finance, ERP and CRM applications. In terms of Identity Management and compliance however, we tend to hear a lot more about identity and user account focused access controls, attestation and segregation of duties (SoD). The products in this area receiving the most press of late are SailPoint's IdentityIQ and Aveksa's Compliance Manager.

Oracle's GRC product doesn't actually compete in the identity-centric GRC area (at least not directly). But in light of Sun's very recent launch of its Identity Compliance Manager and Novell's entry into this space through their Access Governance Suite (which is actually Aveksa re-branded via an OEM agreement), I wanted to know if Oracle had any plans to expand their GRC offering to address identity-centric compliance.

Amit's answer was that Oracle does in fact have plans to do this and they are looking at expanding the capabilities of the existing GRC product instead of building a brand new one. This essentially means that the GRC product will get additional features and hooks into the Identity and Access Management suite and vice versa. This includes things like building on the existing attestation capabilities of OIM and supporting the ability to deal with SoD policies through mining existing user entitlements and also using preventative measures (like CA will have once they finish integrating the features of the recently acquired IDFocus product).

Despite Amit almost calling me a journalist on the call, I'm far from one. What I'm trying to say is that I didn't really take any notes. I just spoke to him about a topic I find very interesting and now I'm writing about it. Hence if any of you in the Oracle community (Nishant? Clayton? Mark? Anyone else?) want to confirm, deny, correct or add to any of this (or part 1) feel free to do so via the comments. If not, we'll all just take everything I've said as fact and hold product management to my claims :-)

Ultimately, talking about plans which make a lot of sense means very little other than to communicate intentions. They key will be how Oracle executes and how quickly they do it. Otherwise, they might as well be telling us they want to put a guy on Jupiter.

Some answers on Identity enablement

James McGovern has a habit of posing questions and then naming the people he would like to answer them. This time around, I had the privilege of having my name read out on the roll call. Actually he posted it just before I went on my week-long holiday hence I'm only getting around to it now.

Here are his questions (in blue) and my attempts at some answers (hopefully I don't sound like a complete fool - I'll settle for mildly foolish):

[JM] Protocols:Nowadays, the folks over at the Burton Group such as Bob Blakely, Dan Blum and Gerry Gebel have put together the most wonderful XACML interoperability events. The question that isn't addressed is if I am building an enterprise application from scratch, should I XACML-enabled, think about integrating with STS, stick to traditional LDAP invocation or something else?

[IY] I'm not 100% sure what James is asking and my answer will probably be different if James actually means something other than what I've interpreted it as. I read the question as being once the decision's been made to use XACML, how should one be dealing with authentication? Talking about an STS (I assume James means Security Token Service) vs LDAP refers to 2 different "layers". In reality nowadays, you're ultimately authenticating to a directory of some sort. Usually you do this using the LDAP protocol under the covers. Whether you know this or not depends on the overall design.

Note that using XACML means you are pushing policy definitions around to ultimately get your Policy Enforcement Point to be able to come up with an authorisation decision. When you talk about STS or LDAP, you're typically referring to authentication which ultimately produces some sort of credential for the user within their session. Authentication and authorisation (or entitlements as people seem to like calling it nowadays) are related, but separate things that can be implemented differently as long as there is a point where they interoperate. Usually the most important part is where the authentication mechanism passes the security principal onto the authorisation mechanism so it can make an identity based, access control decision (that is also hopefully fine grained and context aware).

That said, I'm going to ignore the XACML consideration for a moment...

There are a few common approaches to take when writing authentication for applications:
1) Take a service-oriented approach (e.g. SOA or web services)
2) Leverage an API or application programming standard (e.g. JNDI, JAAS)
3) Use the native protocol of the authentication store (e.g. LDAP, SQL)

Option 1 is the most difficult to set up because this type of infrastructure is typically not built in organisations today. But it IS the most extensible option and hides the implementation specifics from every application that needs to perform authentication. Whether the underlying store is a directory, database, file system or even a mainframe does not matter. You also get the benefits served up by leveraging a web service. For example, you just need to know how to format your message (this is actually not a problem if you use a standard as it is usually taken care of by some other service) and where to send your request (via the URI). You obviously also need network connectivity to that location. There are no headaches around what libraries to import, whether your authentication services are co-located with your application or whether you need to go screw around with configuration settings and files because you are actually calling a service that is not located on the same application server as you. Keep in mind that you don't necessarily have to use an STS, although it is probably the best approach today if you're going with a service-oriented design.

Option 2 still leverages standards of sorts. JNDI and JAAS for example are both standards in their own rights. They just happen to be tied into a programming language and platform. This option is probably still easier than option 1 because organisations will more than likely have this infrastructure more or less set up. It's a matter of getting the programmers to code to these standards/APIs and then setting up the application infrastructure to hook into the relevant authentication stores. Again, this is probably already done if you're using a standards-based Application Server (e.g. J2EE). You will however, have configuration files to screw around with and changes to any of the infrastructure will potentially require applications to be modified. You're also tied into the platform somewhat. For example, if you use JNDI you're stuck with Java and the directory under the covers. With a web service, it doesn't really matter what programming language is used or what the authentication store is. You can swap components out without modifying the other loosely coupled pieces. You're supposedly able to do this easily if you code to API standards, but that's rarely true. There's usually re-configuration and some re-writing required.

Option 3 requires intimate knowledge of the protocol or tools required to access the authentication store. If using LDAP, you need to know LDAP query syntax. If using SQL, you have to know how to write SQL queries or stored procedures. It also means you cannot change your authentication stores and schemas without re-writing your applications.

They each have their benefits, but it boils down to the age old discussion around tight coupling vs loose coupling. The looser the coupling of your infrastructure components, the more extensible they are. You lose performance however and it usually takes more effort and time to build a loosely coupled system because of all the design considerations to take into account. (Note: The performance issue is usually one that can be designed around if you have the budget. You put enough redundancy, load balancers and hardware in place and you can usually get something to perform within your service level agreements (SLAs). If your network hops are large, just do a better job of negotiating your SLAs - easier said than done I know).

Option 1 is the loosely coupled approach which should "identity proof" your environment for a longer period of time (notice I didn't say forever). Option 3 is the tightly coupled approach. Option 2 is something in between. The one to pick depends on requirements, time and cost constraints. The choice will be determined by how much of the authentication infrastructure specifics you want to burden your developers with.

Bringing the XACML considerations back into the picture, I would go for option 1. If you're going to take the effort and XACML-enable your applications, why would you "get cheap" and not go with the use of an STS? It also makes everything nice and clean from an application programming standpoint. Developers will only have to worry about using security services. They won't need to remember that for certain security related things, they need to use the web service while for others they have to use the API or go direct to the source over LDAP or SQL.

[JM] Virtual Directories: What role should a virtual directory play in an Identity metasystem? Should virtual directory be a standalone product in the new world and simply be a feature of an STS? If an enterprise were savage in consolidating all directory information into Active Directory, why would I still need virtualization?

[IY] I don't come across too many organisations that use a virtual directory. Maybe it says something about the maturity of their Identity Management infrastructure. Or maybe it means that they don't see the need and are quite happy replicating things using meta-directories and synchronisation.

Leveraging a virtual directory is very much a technology choice and dependent on each organisational environment. If they have lots of identity stores and have a nightmarish amount of information that would take a long time to integrate and synchronise, then a virtual directory makes sense. If an organisation has a fairly small number of stores or their strategy is to leverage a specific central store like Active Directory, then they probably don't. On the flip side, one could argue that the virtual directory could become this "central store".

I'm not for or against virtual directories. I just think there's a time, environment and place for the choice between a virtual directory or a synchronisation solution like a meta-directory. As for using a virtual directory as part of an STS, the argument is very similar to what I've just outlined.

[JM] Entitlements: One missing component of the discussion is authorization and their is somewhat too much focus on identity. Consider the scenario where if you were to ask my boss if I am still an employee, he would say yes as he hasn't fired me yet. Likewise, if you ask him what are all of the wonderful things I can access within the enterprise, he would say that he has no freakin clue, but as soon as you figure it out, please let him know. Honestly, even in my role, there are probably things that I can do but shouldn't otherwise have access to. So, the question becomes how come the identity conversation hasn't talked about any constructs around attestation and authorization?

[IY] People are too busy crapping on about OpenID and CardSpace all the time :-)

Seriously, I think it's got to do with the way things in the identity space evolve. Before you can deal with entitlements and attestation, you need to know who people are and what they can use (i.e. what they can "log into"). It's a very high level approach sure. But that's how organisations typically start looking at the whole issue.

Also, Identity Management is not an easy issue to solve. As a result, it's taken a long time to get around to thinking about authorisation properly. It doesn't mean we will never get there. We just have to be a little more patient. All the GRC initiatives going on around the place are certainly helping. Attestation is usually one of the first things that get addressed in any GRC initiative because it needs to be done to satisfy the regulators and auditors.

Once organisations realise that having a proper authorisation infrastructure in place makes their lives a lot easier from a management and audit perspective AND it'll save them money (instead of having to re-invent the authorisation wheel for every application), they'll start to do something about it.

It's also about evangelism, education and focus. The focus isn't there yet so there's no education. Evangelism comes from the industry as a whole. The large vendors are usually the ones with the marketing clout to get the messages out in a meaningful way. Unfortunately, they chase the dollars. Until recently, there hasn't been sufficient sales revenue or qualified opportunities to justify evangelising authorisation. It's the next cab off the rank I think. We might have to wait a year or 2 for organisations to get through the early phases of their GRC initiatives before authorisation gains real traction.

[JM] Workflow: Have you ever attempted to leave a comment on Kim Cameron blog? You will be annoyed with the registration/workflow aspects. The question this raises in my mind is what identity standards should exist for workflow? There are merits in this scenario for integrating with the OASIS SPML standard, but I can equally see value in considering BPEL as well.

[IY] I don't think there needs to be identity standards for workflow in the traditional sense of technical standards. A generic workflow standard (e.g. BPEL) across all disciplines is good enough and will be better in the long run. Workflows are very dynamic, can get very complex and will be different for each organisation even if they are trying to do similar things. This makes standards tricky. Then there is also workflow from a business standpoint. When technical folk talk standards, they usually mean nuts and bolts (e.g. XML specifications). Those in the business world don't care that a worklow is written in BPEL. They care that they have to write a frigging workflow procedure from scratch. They would probably find some standards around business process definitions useful. It might be prudent of us to define easily extensible procedural workflow templates for Identity business transactions perhaps? Now that would REALLY be something.

[JM] Education: Right now the conversation regarding identity is in the land of geeks and those who are motivated to read specifications. There is a crowd of folks who need things distilled, the readers digest version if you will. Traditionally, this role is served by industry analysts such as Gartner and Forrester. What would it take for this guys to get off their butts and start publishing more thoughtful information in this space?

[IY] I don't think industry analysts are ever going to write a "readers digest" version of anything related to Identity. It doesn't help them make more money from selling reports and holding conferences for specialised groups of people while charging them thousands of dollars each. Unfortunately, I think the fastest way to get simplified Identity education out there is through the marketing dollars of the large vendors. Consulting organisations (including analysts like Gartner and Forrester) will never simplify anything because they need for things to remain (or sound) complex so they can keep charging for their "expertise".

[JM]Conferences: When do folks think that the conversation about identity will occur at other than identity/security conferences? For example, wouldn't it have been wonderful if Billy Cripe, Craig Randall and Laurence Hart where all talking about the identity metasystem in context of ECM?

[IY] Ummm how about never...which is fine by the way. The Identity industry needs to make things so dead simple and ubiquitous that there is no need to talk about it. It should just be there. Therein lies the challenge facing us all today.

Cisco wants an identity and entitlement aware network

I've mentioned Securent a couple of times before and have had various opinions about the company and Authorisation/Entitlement Management in general. I've even had a bit of a debate with its CEO Rajiv Gupta both online and offline (via email).

In one of the "what the F*$&" moves of recent times, Cisco just acquired Securent for $100 million. In a side note, Securent curiously also announced guidelines and tools for centralising the management of entitlements. I think this is somehow going to get lost amongst all the talk about the acquisition.

There's plenty of informed commentary about it by Dave Kearns, Jackson Shaw, Ian Glazer, the Burton Group, and Dark Reading so I won't comment too much other than to say I agree with a few things various people have said:

1. Securent will form the basis of Cisco's centralised, network based entitlement/authorisation service. Why? Because Cisco said so.
   
2. Cisco is trying to bridge the gap between Identity on the network and Identity in the application world. They are not the only company doing this, but they are the most influential because they are Cisco. It's still true that in many circles today, the network = Cisco.
   
3. Cisco understand (or at least hopes that organisations understand) that Enterprise Identity and Access Management needs the network to play its part around user identity and context to have a truly coherent enterprise security infrastructure that works. I'm not saying it's easy. I'm just saying it needs to happen.
   
4. Securent will get lost in the big juggernaut that is Cisco, be consumed and eventually forgotten by virtue of being absorbed into a company as big as Cisco. So much for that great marketing team I've complemented before.
   
5. Why the heck did Cisco start its march into the identity space with Securent? It's a little puzzling, but I suppose the other "hot mature vendors" had already been gobbled up by the likes of IBM, Oracle, CA and others. Cisco is behind in this space. The fastest way forward when you are behind is to be disruptive. Maybe that's what they are going for. They need to be relevant in this area if they are to continue being dominant in the networking world.
   

In good company

The guys over at Securent have started a blog dedicated to discussion around entitlement management (EM). It'll be interesting to see what type of content gets posted on there and exactly how much discussion it will facilitate. They're off to a decent start I suppose, getting Gerry Gebel from the Burton Group to contribute. There's no real meaty content yet however. Securent CEO Rajiv Gupta's entry is the stock standard spiel about EM.

The only reason I found out about this site was through referrals to my blog. I'm starting to see traffic from www.entitlementblog.com and was wondering how in the world this was happening. So I checked it out and was surprised to see my name on the blogroll amongst some illustrious company.


I thought I should take a screen shot before they realise I'm not worthy of being amongst the names on that list :)

Securent bandwagon getting heavier

One of the most widely read posts on this blog is my rant on entitlement management and Securent. If you've read it, you might have also noticed my "conversation" with their CEO Rajiv Gupta in the comments (incidentally, I never did get a response to the last email I sent him asking for a clarification - but I'm sure he has better things to do than debate the point with me...like marketing his product for example).

They've been getting more and more positive press coverage lately (here, here, here and here). And this week one of the louder voices in the identity community also jumped on the bandwagon. Dave Kearns made mention of Securent in this NetworkWorld article a few days ago. Again, it was positive.

I'll say one thing. Their marketing department is doing a great job of positioning Securent in a positive light in the marketplace. I have yet to see any negative buzz relating to them (apart from my rant). They've also recently announced the expansion of their leadership team so they are obviously doing very well.

I have nothing against Securent and their place in the market. More power to them for attacking the niche of authorisation management and realising it's been the poor cousin to identity management for awhile. Shame on IBM, CA, Sun, Oracle, BMC et al for not realising the potential and doing something about it...from a marketing standpoint (actually CA sort of have, but they only made a half hearted attempt and have not gotten any mindshare).

And that's exactly my point. Securent are winning on marketing. Their decision to use "entitlement management" to differentiate themselves from the pack has been a masterstroke. The less informed amongst us seem to think just because it's not a term they've heard before, it must be new. It's not. Like I've been saying over and over again, it's just authorisation/access management re-badged. Anyone who believes otherwise has been "marketed".

Entitlement Management is NOT a new concept

Seems to be a fair bit of hype and marketing about the supposed "new" area of Identity Management called "Entitlement Management" and a particular startup called Securent. InternetNews.com, NetworkWorld and DigitalIDWorld (to name a few) have all talked about it as being the "new frontier" even suggesting that Securent is the only startup in this area.

I beg to differ and I'd be willing to bet any vendor or startup out there dealing in network or application access control will no doubt have something to say about that. It's just that it hasn't been marketed well enough in the past. This type of "entitlement management" technology has been around for YEARS. In fact, many of the access management products on the market are built on this type of idea and most offer APIs to allow the externalisation of entitlements. The only thing missing with many of the existing products out there is an XACML interface into them - and I dare say this is being rectified in a hurry.

All the hype-mongers out there should look a little deeper into the solutions out there before "announcing" the arrival of the "next big NEW technologies" and further adding to the hype. Perhaps organisations are starting to take a look at "entitlement management", but it's not new. The only thing that's happening at the moment is that marketing is catching up with the technology. Maybe the marketing departments have leaped on this concept as the next thing to go after because most of the other areas have been marketed to death.

It kind of makes sense because vendors are now beginning to work their way down the application stack in the identity space. Perhaps market research has also helped determine that the security maturity lifecycle of organisations is at this stage in their identity and access implementations. Regardless of the reason, the industry seems to have reached the point where it makes sense to specifically market fine-grained authorisation as a key component. In the past, this was simply "value-add".

InternetNews.com goes so far as saying some vendors don't have solutions in the "entitlement management" space and singles out IBM in particular. The writer of that article should really do his research a bit better. I have a tip for him - go read up on IBM Tivoli Access Manager.