One of the most common questions I encountered at the Catalyst conference this year was “what is application-centric IdM”. The second most common question (did not lose by a lot) was “how does this compete with user-centric identity”. It has taken a while, but I wanted to make an attempt at answering those questions in a broader forum.
What is “application-centric identity management”?
Application-Centric IdM is one of 3 pillars around which we are building our IdM offerings. It is an offshoot of the broader application-centric security concept being woven into everything coming out of our middleware group. The application-centric philosophy is about understanding the needs of applications and application developers. A lot of the problems we face today in identity management stem from the fact that when it comes to identity, each application is on its own. Every time an application is being developed or deployed, the ones responsible for it – the architects, the developers, the project managers and the administrators – are forced to tackle the same old issues over and over again. How do I deal with authentication? Where do I get the user’s identity information from? What identity information do I need based on the problems I have to solve? How do I make sure it is correct? The answer to these questions is often so hard, that the development teams deal with it in the way they know best – they build their own identity infrastructure. They create user tables, login screens and processes, permission and authorization modules, account registration procedures, and profile management tools. And they do it again and again. The result is what we see today – multiple identity silos in the organization that require complex management software, tools and processes as add-on layers to try and give the enterprise some semblance (illusion maybe?) of control; poor application security with no real mechanism for consistent, centralized enforcement of enterprise-wide policies like SoD and RBAC; and users having to deal with multiple passwords, multiple authentication schemes, multiple profiles to manage…the list goes on and on.
Enterprise IdM solved this somewhat by adding an additional layer of abstraction on top that solves some of these issues. Centralized profile and password management, SSO tools and Audit & Compliance solutions took away some of these issues. But this added additional challenges into the mix in the form of complex integration problems, and the need for complex tooling and processes.
As long as IdM follows the bolt-on systems management approach, these challenges will only be mildly alleviated, and never truly cured. This is where application-centric IdM tries to provide a new way of solving this age-old problem. The idea is that instead of each application having to build these infrastructures as part of their functionality, they can just avail of them as ready made, standards-based services. Application-centric IdM moves away from the traditional system management style of IdM, focusing instead on the creation of an IdM infrastructure that customers deploy to expose these services for their applications to plug into their own business processes. It makes identity (and security) an integral, yet abstracted part of the development process. This separation is critical, because often the people defining the security policies are not the same as those defining application behavior – similar to how the role of deployers and developers is separated in J2EE. At the end of it all, users get a consistent experience, the enterprise gets better control of security, audit and policy enforcement, the IT department avoids massive data and process management problems, and developers can better focus on the business functionality of their applications.
How does this compete with user-centric identity?
The simple answer is that it doesn’t! Application-centric IdM is completely compatible with user-centric identity. In fact, it can help with the introduction of user-centric identity into the IdM equation. As user-centric identity gets incorporated into the operational environment, applications that have plugged into an application-centric IdM framework will be able to immediately take advantage of it, because it will become available as an underlying service in the infrastructure. The same identity retrieval service that the application was using to retrieve identity data from the corporate directory can also retrieve identity data from the identity tokens that the user provided during their session initiation. Without having to change anything, the application can now consume user-centric identity tokens. The basic value proposition is that applications no longer worry about how they retrieve the identity data they need. They have a common service to get it from, which allows it to plug into the wider identity world underneath in a transparent manner.
To find out more about Application-Centric IdM, click here. And be sure to stay tuned as I delve deeper into this emerging concept, providing you insight into how we are looking to solve some of the problems that have vexed you for many years now.