The problem with Identity Services

This is an interesting time for me at Oracle. One of the reasons why I haven’t been active on this blog for a while is that I have been immersed in discussions about fusion architecture and how identity services fits into it. Those following my blog know that one of the initiatives I have been involved in is the definition of Fusion Identity Management, a layer in the architecture of Fusion applications that provides identity management services for the overall deployment. Last week I was at Oracle HQ participating in a series of meetings on the viability of identity services in fusion architecture. The question is not whether identity services is part of fusion architecture (it is, of course), but rather what form it will take.

Any question about the viability of identity services is tightly tied to the viability of SOA in how enterprise applications are built, something which is being strongly questioned in the industry (the sheer number of articles, blog posts and analyst reports with the words “SOA”, “myth” and “reality” in the title is an indicator of that). The big issue in any SOA debate tends to boil down to performance and availability concerns.

Also muddying the waters in the fusion discussion is the blurry boundary between identity data and HR data. HR is universally acknowledged as an authoritative source of identity information in an enterprise context. However, it becomes problematic when we have to divide up the data that HR masters into identity data that applications come to the identity service to access and HR data that applications (which by definition would then be tied to HR) go directly to HR to access.

One of the reasons why Fusion Identity Management is more than just the typical identity services discussion is that the nature of Fusion Applications is much more complex than the typical application that we consider when we talk about identity services. In Fusion architecture, we are talking about managing identities in thousands of applications across a few application pillars, with some pretty complex interplay among them. Externalizing identities and roles becomes a lot more complex (and at the same time a lot more important) when security is being integrated into every tier of such a complex mega-application architecture, be it UI, business logic, middleware or database. And when I heard about the need to support disconnected mobile applications with no connection to that identity cloud in the sky, I found myself reaching for the Tylenol.

All this means that those of us working on identity services have some pretty tough questions to answer.