Without revealing too much of our “off the record” conversation, let me say that I left that call with the same frustration I’ve begun to express here as of late: we’re still building identity infrastructure and have not yet moved to identity applications.
[From From identity infrastructure to identity applications | CSO Blogs]
Yet surely almost everything is an identity application. It doesn’t matter whether it’s payroll, customer service or anything else, identity should be used as an integral part of all applications. Not in the simple “government” sense of requiring a single, unique identity for administrative convenience but integral in the sense of drawing on a common set of resources to make all of the applications not only more secure but easier to implement.
There’s a link between this kind of thinking and the architecture it leads to. If you think of “identity” as a kind of box in which to store some personal data, then you tend to think of applications in different silos dipping into the box to take the data that they need. SImilarly, if you think as “identity” a single, unvarying dataset then you will use it, generally inappropriately, in all circumstances. In almost all of the identity applications that are discussed in the corporate environment, identity is irrelevant to the task in hand and bringing identity into the equation makes matters worse (because it makes for more places, more transactions where identity can be stolen from or abused). What’s at issue — whether I’m trying to log in to our VPN and get into the server room — is permission.
I can’t help feeling that part of the problem is that identity management implementation in a large organisation does not begin from an infrastructural perspective or from a long term strategic framework, but from fixing the mundane problem of log-in and then building out. This is the wrong foundation, surely, but you can understand why it happens.
However, the identity and access management vendors discovered that E-SSO was both a market accelerator and offered some important features of interest to customers with regulatory compliance requirements. E-SSO has a shorter sales cycle (typically six months or less) and is able to deploy more rapidly (one to three months depending on the complexity of the environment). Cost for E-SSO varies but many deals are less than $100K, which is easier on the IT budget than most user provisioning software and service projects. Customers could start with E-SSO and then over time add user provisioning, web SSO, federated SSO, and other components of the identity management suites.
[From Burton Group Identity Blog: Why Enterprise Single Sign-On (E-SSO) is More Than Just a Tactical Add-on]
So what they are saying here is that while corporates want to build identity management infrastructure, they do so by building on SSO, an approach that doesn’t seem to be getting us anywhere.