What is federated Identity? How it works and its importance to enterprise security – Source: www.csoonline.com

At the very heart of enterprise security is the tension between convenience and safety. The business longs for the ease of users, in competition with the demands of security. Authentication is a main theater for this tension, directly impacting the onboarding and login experience. Federated identity is at the forefront in addressing this tension, affording a good user experience without sacrificing security.

Federated identity management (FIM) makes it possible to share a single digital identity across many services. As end users, we are familiar with the experience of logging into an application using an account from a third party: for example, logging into Twitter using your Google account. This is one form of FIM.

Federated identity management enables capabilities not achievable with any other means, capabilities that can mean big wins for user experience, overall security, and resilience. The tradeoff is in increased architectural complexity, vendor lock-in, and service costs.

Identity access management (IAM) is the general field of digital identity and access and FIM is the branch that focuses on securely enabling a single authentication event to cover multiple interactions or identity information sharing. FIM is sometimes conflated with single sign-on (SSO) but strictly speaking, SSO is a feature of FIM, one of its main use cases. And it’s not to be confused with self-sovereign identity, also known as decentralized identity, which uses blockchain to register the attributes of a person’s identity.

The benefits of federated identity management

However you define the terms, the bottom line is that when you are looking to simplify your users’ login experience by allowing them to log into multiple applications with one set of credentials, you are in the realm of federated identity management.

FIM has many benefits, including reducing the number of passwords a user needs to remember, improving their user experience and improving security infrastructure. On the downside, federated identity does introduce complexity into application architecture. This complexity can also introduce new attack surfaces, but on balance, properly implemented federated identity is a net improvement to application security. In general, we can see federated identity as improving convenience and security at the cost of complexity.

Single sign-on and federated single sign-on

There are two basic types of single sign-on: what applies to applications within a single organization and what applies across organizations. Usually the former is called simply single sign-on, or sometimes “enterprise single sign-on”. The latter is called federated single sign-on (FSSO). It can cause confusion with the terms federated single sign-on and federated identity management. FIM covers both types of SSO.

To achieve SSO of any form, the high-level architecture looks like Figure 1.

Matt Tyson

In the diagram, there is a central federated identity manager. In all cases, there must be some central authority that brokers the shared credentials between diverse services. This can be an identity manager built by the organization itself (using active directory or some other identity repository) or offloaded to an identity provider (IdP) of varying degrees of comprehensiveness.

Enterprise single sign-on often covers situations where employees are finding they must log in multiple times to internal systems, for example, one login for the HR portal and another for the IT ticket system. There are obvious user experience problems with this arrangement, but also systemic ones, in that identity information is distributed among heterogeneous systems, making it less secure and more difficult to enforce policy. For example, in this situation, when an employee is onboarded or off-boarded, two different data stores have to be modified.

Sharing credentials across boundaries

Federated single sign-on allows for sharing credentials across enterprise boundaries. As such, it usually relies on a large, well-established entity with widespread security credibility, organizations such as Google, Microsoft, and Amazon, for example. In this case, applications are usually gaining not just a simplified login experience for their users, but the impression and actual reliance on high-level security infrastructure. Put another way, even a small application can add “Sign in with Google” to its login flow relatively easily, giving users a simple login option, which keeps sensitive information in the hands of the big organization.

The “Sign on with X” style of login is sometimes called “social sign-on” because it is associated with big social media, for example, “Sign on with Facebook”.  To add to the potential for confusion, the specific capability of sharing identity information between applications and services is sometimes called “identity federation”. This is another aspect of FIM, also called identity information sharing.

Implementing FSSO

Building an FSSO solution is guided by the specifics of the requirements, however, the general steps are the same:

• Establish an identity provider. One or a blend of:
  • Deploy a centralized identity infrastructure.
  • Establish an account with a federated identity provider. There are many, like Google, Microsoft, Okta, etc.
• Configure the provider with your application information. This means configuring the provider with the information that will allow the applications to connect to the provider.
• Add credentials for the provider to the applications. These you will use in the next step to tell your apps how to authenticate.
• Set up the apps. In your application code, you add dependencies for authenticating and interacting with the IdP service.
• Integrate the new authentication flow. Using the configured SSO service, provide users a way to authenticate their session with it. This can be done transparently, where an app will automatically detect and authenticate a user with a live session from another service.

Because of its ease, most enterprises today choose to use a SaaS style cloud IdP for both enterprise and federated SSO. An IdP will allow for interacting with an API for both the establishment of a relationship between the services and in negotiating the actual sign-ons. The typical SaaS trade-off applies, where you gain simplicity and power at the cost of paying for the service and risking vendor lock-in.

Hoe to implement SSO protocols

There are three main protocols in use for SSO interactions: SAML, OIDC and OAuth 2.0. Depending on what the ID Provider you are using supports, you will use one of these to communicate the secure token information between your applications.  Each of these is an open standard supported by the industry and focused on a particular use case.

SAML: An XML-based protocol that is commonly used in the enterprise setting to support enterprise SSO or to move across business service providers (like logging into Salesforce without having to authenticate again). It can also be used in general identity sharing including federated SSO (if the IdP supports it). SAML is the oldest protocol (begun in 2002) and helped to inspire the others.

OAuth 2.0: An authentication protocol that allows for sharing of resource information between providers based on user consent (like if you’ve ever clicked ‘allow application to access this information’ for example, when enabling a third-party tool access to GitHub information). Oauth 2 is focused on sharing authentication between services without providing credentials.

OIDC (OpenID Connect_: A layer built atop OAuth 2.0, usually used for the kind of social login mentioned earlier (e.g., “Sign in with GitHub”). OIDC includes a few add-ons to OAuth, including identity assertions, userinfo API, and standard discovery – in general, standardized mechanisms for providing and consuming identity information securely.

These are used alone or in conjunction with other technologies. For example, JWT (JSON Web Tokens) can be used to encapsulate OAuth 2.0 credential token information in a more secure format.

In most cases, you will identify what parts of your infrastructure can benefit from SSO, then identify what is the best IdP for your situation, and based on what protocols they support, determine how to integrate them into your specific technology stacks.

Fortunately, the process for implementing these protocols is well understood and supported in a wide range of technology stacks. Most of the work is encapsulated by higher-level abstractions, in many languages and frameworks. For example, Spring Security has SSO support and so does Passport in the NodeJS/Express ecosystem. In some cases, like adding social sign-on buttons, it can be very simple indeed to implement the happy path. From there the complexity grows depending on how custom the requirements are, how many components are involved, and what the existing security systems look like.

When considering an IdP as a partner, it’s important to consider cost and features, but also the synergy of its offerings with your planned or actual technology usage.

Matthew Tyson is a founder of Dark Horse Group, Inc. He believes in people-first technology. When not playing guitar, Matt explores the backcountry and the philosophical hinterlands. He has written for JavaWorld and InfoWorld since 2007.