From federated identity to consolidated identity: a look at the past, present and future


This post was also published in CIO.com.

It’s time for a better way to maintain identity in the enterprise. Let’s explore a new identity model, Consolidated Identity, that will simplify how employees authenticate into systems, access data and complete workflows.

Today, it is common to use your Google, LinkedIn, or Facebook identity to log into a website. However, in the first generation of the commercial Internet, this was not the standard experience. Virtually every internet service required users to create an account with a username and password. For services that were only used occasionally, having to create this account and remember all the associated passwords often created friction for new users.

The invention of federated identity for the consumer Internet

I worked for Sun Microsystems in the early 2000s and was fortunate enough to be the technical lead for a new concept called federated identity, which presented a way for separate online entities to share identity across any number of websites. In order to build it, Sun formed the Liberty Alliance, a consortium of large companies from a variety of sectors, ranging from telecom to travel to banking.

With federated identity, we separated two important concepts:

  • Logging into a website
  • Using a service from a website

Using a standard protocol, a user could, for example, log into Aol.com and then go rent a car from Hertz.com without having to log into their Hertz account. Federated identity allowed distinct websites to enter a business relationship with each other. Using a standard protocol, a website, such as Aol.com, could operate as an identity provider where users had an account with login credentials, while another website, such as Hertz.com, could operate as a service provider where users could then rent a car. As a result, users benefitted from simplified access to services using their pre-existing accounts.

User identity on the consumer internet

Federated identity was built on a loose trust model, which placed a firewall between users’ account information and their service history across providers. In other words, there was no need for AOL to know anything about your rental car history or for Hertz to know your AOL preferences. With the Liberty Alliance, we created extensions to the protocol that enabled services, such as user information transfer and payment processing, to be exchanged between providers.

The adoption of federated identity in the enterprise

The protocols of the Liberty Alliance became the basis of SAML 2.0 when they were transferred to the OASIS standards organization. Accelerated by the prevalence of identity servers and identity access managers that supported the SAML standard from vendors, such as Sun, Oracle, and CA, enterprises embraced the SAML 2.0 protocol as a standard way to perform single sign-on (SSO) across enterprise systems.

However, SSO is only the first step for a successful enterprise identity model since, unlike consumer internet and service providers, enterprise systems have a tight trust model. Many enterprise identity and service providers are hosted by the enterprise itself, and external service providers are subject to intense security controls and compliance to ensure that employee data remains secure.

A direct consequence of federated identity is that all of the data related to an identity is also federated across countless systems. Employee data, for example, is hosted in numerous systems, including payroll, human resources management, and financial and ticketing systems.

Consolidated identity is an evolution of federated identity, specifically for the enterprise. In an organization, there is no need for the firewall between the identity provider and the service provider. The enterprise itself is the primary identity provider and the service providers that provide services, such as payroll and time off requests, do not hold any data that should not be accessible to the enterprise.

In the enterprise, each employee has data spread across dozens of systems, and unfortunately with federated identity, there is no way for the employee to cross those silos – the employee has to log into each system and use its interface to access the data they need. That’s where consolidated identity comes in, providing employees with the same simplified access to their business services that federated identity delivers to consumers.

Here are the five steps to consolidating identity in the enterprise:

  1. Determine which authentication systems are in use and chain an employee’s identity across those systems. A typical enterprise uses one or more directories, such as Active Directory or LDAP, and enterprise mobility management systems.
  2. Consolidate the data associated with an employee. While it is considered incredibly difficult to integrate widespread data, it is much more efficient when the use case is narrowed. Typically, it is only necessary to consolidate the “active data” related to an employee. For example, the requests of the consolidated identity system could be only for open time off requests, rather than every time off request ever made for both active and inactive employees.
  3. Control how data can be accessed. A consolidated identity framework must also include a copy of the rules for how any cached data can be accessed. Most systems use declarative access rules and groups that can be copied along with data to ensure that data is only viewed by appropriate parties. Combining the rules that control how data is accessed with the data itself is a much more efficient mechanism than using mechanisms like data warehouse slices.
  4. Control access to functions, such as micro apps, with identity provider and application groups. In a typical enterprise, there are Active Directory groups, such as “Management”, as well as groups defined within applications like “ServiceNow Administrators”. A consolidated identity system needs the capability to validate a user’s membership in an application’s security groups.
  5. Facilitate writebacks to source systems. This can be performed using an application API with a service account and delegated authentication or a record notation of who performed an action. Another option is to leverage SSO to either deep link into a target application, so a user can perform an action within it, or have the user bounce to an application login page and login via SSO in order to get a user token to pass to an API.

Consolidated identity and the identity graph

A consolidated identity system evolves federated identity by creating an aggregated store of each employee and their entitlements across both identity providers and applications. This “identity graph” enables a new wave of applications that are both employee-centered and secure in authentication, authorization, and data governance.

For more, check out this whitepaper on consolidated identity that I wrote.