The popularity of entitlements, both as a noun and as a thing, is rapidly growing in the IDM world. Before entitlements became an oratorio impossible to ignore even with the best Jedi mind tricks, there was a flutter of butterfly wings. That is, 2-3 people in a hallway at a conference started whispering entitlements,entitlements,entitlements . Then came presentations, then whitepapers from analysts and vendors and finally the Market noticed that, wait, what about entitlements? The chaos theory refers to the initial whisper event as a butterfly effect, there's no other explanation for their sudden rise to fame. I mean, it's not like they didn't exist, they were just invisible to the human..err...auditors' eye. Hail Eris!

Much to the delight of those semantically inclined, the definition of the noun entitlement has proved hard to nail down in the identity and access management context. While we were feeling smug and entitled, we've written a blog post on the subject along with a whitepaper (registration required) that talked about the challenges of managing entitlements throughout their lifecycle. Let's see some popular definitions of entitlements:

Webster / Wikipedia: A right to benefits, esp. by law or contract

Burton: Object in system’s security model that can be granted or associated with a user account to enable the account to perform (or prevent performance of) a set of actions on the target system

BEA (now Oracle!): Set of privileges that govern what an application user can do

Identigral: A business rule expressing actions that can be allowed or denied

From our perspective, it doesn't really matter that the entitlement is granted to an account, a user, an application (yes, applications have entitlements too!) or some combination thereof. The act of granting and the subsequent association between an entitlement and its subject (owner) is not relevant to the definition of entitlement. Webster is closest to what we feel is the best definition. Let's consider an example somewhat divorced from technology.

In a mythical company Ourbont (pronounced oooor-BON, yes it's French) there are monthly management meetings. Everyone who manages other people is invited to the management meeting. The security guard at the door personally knows the managers (it's a small company) and on the basis of, well, your persona, does or does not let you into the meeting. You could say that being a people's manager is an entitlement. It was something that was made into 'law' by the contract between the employee and the company at the time of hire. You could also say that being able to attend management meetings is an entitlement, perhaps a derived one, since it follows from one being a people's manager. The latter entitlement exists due to company policy which (loosely speaking) is a form of law/contract.

We continue to believe that enforcing access based on entitlements is a relatively understood issue. Sure, there are implementation challenges but there's an embarassment of riches when it comes to picking products that enforce access. In the Oracle IAM stack alone, you can throw a dart at the wall and hit a product that can check entitlements and allow or deny access:

In order to enforce the entitlement, it (entitlement) must be first provisioned to the target system and second associated with a subject (user, group, application,etc). This is where a lot of painfully expensive steps happen because much of the workflow involves people from different teams. Throw in approval requirements, throw in eventual upgrades of target systems (Oracle e-Business Suite 11.x -> 12.x = potentially thousands of entitlement changes), throw in audit and compliance (does this person still need this entitlement) and you've got an unmanageable mess on your hands. We've seen and tackled this problem of managing entitlements' lifecycle so many times that we've got it down to science. Come to our webinar to find out more about managing entitlements and using Oracle Identity Manager as a platform for keeping them under control.