Per-Application Identity Silo

In the Stone Age, relatively speaking, of computer applications, each application often implemented its own identity repository, authentication, and authorization. A large enterprise company typically had core business applications, such as finance and inventory control systems, and perhaps a few productivity applications. Each application often had its own dedicated database or other storage in which user identities, credentials, and user profile data were stored, and each application prompted the user to log in and then validated the user’s credentials against its own repository of user information. This meant an employee might have a different username and password to remember for each application. It also meant that if some element of a user’s profile changed, the profile change had to be made in multiple applications. Of course, this did not happen reliably if a company had many applications, so user profile data invariably became out of sync across systems. User exasperation with data integrity issues and having to remember numerous passwords was bad enough when there were just a few applications. As the number of applications in an enterprise grew, however, having every application implement its own siloed identity repository and authentication solution quickly became untenable for businesses.

This siloed approach is still used today in many consumer-facing scenarios where a user signs up by providing an application-specific username and password. If a user reuses the same password across multiple sites, a compromise at any one site could put the user’s data at other sites at risk. If a user specifies a different password for every application, they have to remember or securely store the passwords or rely on the security of an account recovery process provided by the application. Either way, consumer users face some of the same inconvenience with this approach experienced earlier by corporate users.

Centralized User Repository

With time, more and more software was written for a wide swathe of business functions. This drove a need for a better approach to identity management. Many companies implemented directory services to house and centralize user identity information. Directory services are optimized for information that is frequently read but infrequently modified, which is often the case for user identity data. Applications were able to use a directory service to store user data and credentials. It was also possible for an application to prompt a user to log in and validate the entered credentials using information in a directory service. Large, on-site commercial business applications targeted to enterprise environments¹ often included support for this approach. This centralized approach offered a significant improvement over the siloed, per-application approach.

The centralization of identity administration and access with a directory service provided many advantages. Directory replication capabilities enabled applications hosted around the world to leverage the same identity information, eliminating data inconsistency issues. The same username and password could be used across applications. A centralized directory service also provided a single point of control at which to implement password policy or quickly terminate an identity if necessary. As a result, directory services became widely adopted, at least in larger companies.

For all their advantages, however, directory services also had some disadvantages. A directory service by itself did not maintain any sort of session for a user. The centralization of identity information in a directory service usually meant a user had only one username and password to remember, but the user still had to enter the credentials into each application’s login screen because each application needed to collect user credentials and validate them using the directory service (in the absence of additional technology). In addition to being an inconvenience, this exposed the user’s password to the applications. A compromise at one application might put other applications at risk. This was bad enough when all applications involved were inside a trusted corporate network. As companies began using cloud applications, exposing directory passwords to cloud applications owned by others would have posed an unacceptable risk. Once again, a better solution was needed!

Early SSO Servers

Several types of what became known as identity and access management (IAM) or single sign-on (SSO) servers provided further improvement. Early SSO servers leveraged the identity information in a directory service, but provided a layer on top of the directory service that maintained a session to remember users that had already authenticated. The way they worked varied, but in a typical approach, an application could redirect a user’s browser to an SSO server to have the user authenticated there and receive the authentication results in a secure, predetermined fashion. If a user accessed a second application, shortly after they authenticated for the first application, the second application redirected the user’s browser to the SSO server² and the SSO server would detect the user’s existing session and redirect them back to the application with a success status without prompting the user for credentials again.

The introduction of single sign-on servers offered many advantages over directory services. Users benefited from the ability to access multiple applications with a single authentication. Security teams appreciated that the user’s static directory password was only exposed to the SSO server, instead of to each application the user accessed. IT departments were happy because it gave them a single place to implement authentication policy and stronger authentication mechanisms.

Unfortunately, there were some disadvantages with early SSO servers in practice. The interaction between applications and SSO servers was somewhat proprietary, and SSO products were often time-consuming to implement. This meant their adoption was more evident in larger companies with resources to integrate applications with SSO servers. A more significant limitation was that single sign-on relied on cookies which, due to browser restrictions on cookie access, meant the solutions worked within one Internet domain such as www.mycompany.com. As many companies were becoming interested in external Software-as-a-Service (SaaS) applications, this was a limiting restriction.

Federated Identity and SAML 2.0

The explosion of new SaaS applications created challenges for managing identities. In the blink of an eye, business teams everywhere could thumb their noses at backlogged IT departments and sign up for SaaS applications with a credit card. Unfortunately, there was often no good way to manage employee identities in SaaS applications. It was difficult for a company to track accounts its employees created in SaaS systems, and users once again had to remember a password for every application. The single sign-on they enjoyed across internal applications didn’t extend to external SaaS applications in other domains.

Fortunately, a new industry standard, SAML 2.0 (Security Assertion Markup Language), had been published in 2005.ⁱ It provided a solution for web single sign-on across domains and federated identity. This happened to be perfect for enterprises with SaaS applications. Although the SAML 2.0 technical overview focused on a consumer-facing use case, SAML 2.0 provided an excellent solution for enterprises needing better control over employee identities in SaaS applications.

With SAML 2.0, SaaS applications could redirect corporate users back to a corporate authentication service, known as an identity provider (IdP), for authentication. Identity federation provided a way to link an identity used in an application with an identity at the identity provider. Companies could now have the advantages of single sign-on with both internal and SaaS applications. Users benefited by having a single username/password to remember. The enterprise had a centralized control point for both internal and external identities and could shut off access quickly at the corporate identity provider if needed. Password policy and multi-factor authentication could be implemented in a single place. In this way, SAML 2.0 solved many identity headaches for enterprises.

Despite being widely adopted, however, SAML 2.0 was no silver bullet. The protocol was designed to cover many scenarios, making it complex to configure and implement. While SAML 2.0 became widely adopted within enterprise environments, there was no viable business model for it to address consumer-facing scenarios. Users were unlikely to pay money for a consumer-facing identity service. As we’ll see later, this was solved by making someone else entirely pay for the service! Another limitation was that SAML 2.0 only solved the problem of authentication. Applications were evolving to architectures based on APIs. As typically implemented, SAML 2.0 solved the problem of authenticating users but didn’t help with API authorization.

WS-Fed

The Web Services Federation Language (WS-Fed) federation framework was created by an industry coalition as part of a larger set of protocols known as the WS-∗ specifications. The WS-Fed 1.2 specification was published as an OASIS standard in 2009ⁱⁱ and provided mechanisms whereby “authorized access to resources managed in one realm can be provided to security principals whose identities are managed in other realms.”ⁱⁱⁱ It was supported by Microsoft’s ADFS server as well as many other commercial SSO products and provided similar functionality to SAML 2.0’s web single sign-on and federation capability. It was taken up in many enterprise environments and, like SAML 2.0, is still in use today in many corporate settings.

OpenID

The original OpenID protocol^iv is worth mentioning for its notion of user-centric identity. With SAML 2.0 only adopted in employee-facing scenarios, consumer users were still forced to register anew at each consumer-facing web site. A new industry group formed to create a solution for what it termed “user-centric” identity, and this gave rise to a protocol called OpenID. In addition to organization-controlled identity providers commonly used with SAML 2.0 and WS-Fed, OpenID included the idea of user-controlled identity for the consumer use case. Consumer users could even set up their own identity provider and point applications to it for authentication. The original OpenID protocol didn’t become widely used, but it did highlight the need for user-centric identity solutions and laid the groundwork for another protocol named OpenID Connect, which we’ll cover shortly.

OAuth 2.0

With Web 2.0 and the rise of social media, many consumer-facing web sites were created that allowed users to upload content such as pictures. This gave rise to use cases where an application needed to retrieve such content on the user’s behalf. For example, a person who uploaded photos to a social media site might want to enable another web site that printed photos (www.photos.com) to access their photos at the social media site. In the absence of a better solution, the user would have to share their social media credentials with the photo printing site. If the photo printing site were compromised, it would put the user’s social media account at risk. The user also had no control over what the photo printing site could do once it had the user’s password for the social media site. A solution was needed that would allow a user to authorize an application at one web site to retrieve their content from another web site’s API, without the user having to expose their credentials to the first site.

The OAuth protocol provided a solution for this use case. The OAuth 2.0^v version of the specification allows a user to authorize one application, known as a client (the photo printing site), to send a request to an API, known as a resource server (the social media site), on the user’s behalf to retrieve data at the resource server owned by the user. To do this, the application interacts with an authorization server which authenticates a user as part of obtaining their consent for the application to access their resources. The application receives a token which enables it to call the resource server on the user’s behalf. OAuth 2.0 solved an important API authorization use case. Given the lack of a consumer-facing authentication solution like SAML 2.0 and WS-Fed, and the fact that authorization servers might need to authenticate users as part of obtaining the user’s authorization consent, it may have been tempting to some to want to use it for more than this.

By this time, there were several social media sites on the Internet, such as Google and LinkedIn, and they implemented OAuth 2.0 to enable consumer-facing applications to retrieve information from a user’s Google or LinkedIn profile. The authentication step performed by an OAuth 2.0 authorization server as part of obtaining a user’s consent might have seemed to some like it could provide a handy authentication solution. There had not been a viable business model earlier for general consumer-facing SAML 2.0 identity provider services. Neither the users, applications, nor anyone else were likely to fund such services.

The rise of social media, however, provided a new possibility for a solution. Social media providers already had to authenticate users for access to their site and when an OAuth 2.0 authorization request was received that required authenticated user consent. If they were to provide a general authentication service, it might attract more users to their platform, and a consumer-facing authentication service would effectively be paid for by the advertising that paid for the social media sites. There was one slight problem, however. OAuth 2.0 was not designed as a general authentication service and could not securely be used for this purpose, at least without proprietary additions to the pure OAuth 2.0 features. (Several social providers that support OAuth 2.0 have implemented such proprietary additions.) Another solution standard was needed.

OpenID Connect (OIDC)

OpenID Connect (OIDC) was designed to provide a key feature needed for an authentication service. Even if OAuth 2.0 authorization servers were capable of authenticating users, the framework did not provide a standard way to securely convey the identity of an authenticated user to an application. OIDC provided a solution for this need. OIDC was devised as a layer on top of the OAuth 2.0 protocol to provide information in a standard format to applications about the identity of an authenticated user.^vi This provided a solution for applications for user authentication as well as API authorization. The implementation of OIDC by widely used social media/service providers like Google, PayPal, and Yahoo provided a solution for consumer-facing authentication services, but there was nothing in the protocol to limit it to consumer-facing scenarios.

OIDC offers benefits to users, application developers, and identity providers. Web site developers can delegate the work of implementing authentication and password reset logic to an OIDC provider. Users benefit because they can leverage one account to log in to many sites without exposing their account credentials to those other sites. Users have fewer usernames and passwords to manage and enjoy single sign-on. Providers may benefit if OIDC support attracts more users to their platform. OIDC provides the web single sign-on benefits that were attractive in SAML 2.0 and, when combined with OAuth 2.0, provides a solution with authentication as well as the API authorization capabilities needed by modern applications.

The previous sections provided a brief history of different solutions for managing identities and authenticating users. We’ll close with a few words on the benefits of standard protocols.

Key Points