I hope everyone in the U.S. had a good Thanksgiving holiday, and I wish everyone globally the best of holiday seasons. I have been speaking to a lot of companies (something this job fortunately gives me the opportunity to do) regarding the topic of entitlement management again, mainly because they bring the topic up.
Some of those discussions give rise to a couple of thoughts that I wanted to share with you. They may be obvious to many of you once I describe them, but writing down the obvious is good therapy for me.
Thought #1: Identity management systems need identity management. When we first developed super-user privileged management systems, they focused on platform environments (e.g. the sacred ‘root’ user) and database systems (e.g. database administrators).
But as I’ve watched identity and access management (IAM) systems evolve, I’ve become convinced that this the IAM application is worth protecting from IAM administrators, i.e. not so much from threats from the outside as from threats within. I’ve noted that many times those administrators and enterprise users who use IAM have the simplest of authentication/authorisation credentials/entitlements protecting that access; this worries me.
Think also of the budding market of cloud computing-based IAM systems, or even enterprises that want access to software as a service (SaaS) applications which in turn are managed by enterprise-based IAM. Is your head hurting yet? OK, let’s throw into that mix the ‘meta-IAM’ coordinators that will manage multi-tenant IAM operations while coordinating between multiple private clouds and plain old enterprise-based application environments.
Do you really, honestly believe that we will automate all of that in our first round through federation and delegation, or will good old-fashioned manual process be involved as well? So what does that have to do with entitlement management, you ask?
The same architectures, feature-function sets and approaches being contemplated and performed today for enabling granularity of access to applications will play a key role in enabling that same granularity to the IAM application on behalf of its users. And I really don’t think we want to duplicate the same mistakes as the past, when we took our time in bringing together provisioning, delegation and entitlement assignment for customers that make up the IAM suite today. This gives rise to another thought….
Thought #2: I don’t think the brave new world of cloud computing and fine-grained access to the services within will be possible unless we finally ‘solve’ the entitlement assignment and resolution issue. Some of my analyst colleagues in other research firms referred to this as ‘dynamic authorisation management’. This is the basic idea of coding applications and services in such a way where entitlement decisions are made external to those applications and services, similar to the way authentication as been externalised over the decades.
I believe this is a prerequisite for applications and services truly designed and delivered for cloud-computing existence. Sure, you can rig up something (APIs? file transfers? humans sending emails?) that will allow cloud computing service offerings to work using traditional security architectures for access, but it is neither sustainable or scalable.
It will be important to have an architecture by which entitlements are used and reported on that is consistent– that is, if you want to make money as a cloud computing participant or gain consistent access to cloud-based services before you die of old age. We will have to bit this bullet sooner or later. I vote sooner.
There are other thoughts, but I’ll halt at this point to see what YOU think about this topic.