Identity as a Microservice

header.png

Overview

Microservices allow applications to be created using a collection of loosely coupled services. The services are fine-grained and lightweight. This improves modularity and enables flexibility during the development phase of the application, making the application easier to understand. When designing applications, identity becomes a key factor to building out a personalized user experience. Identity also enables other microservices for tasks like authorization applications like Axiomatics, single sign-on, identity management and compliance.

However, access to profile data presents a challenge since it is contained across multiple repositories, contained in other applications or even must be consumed from other microservices. The Identity Microservice must be able to not only respond to requests through a standard protocol for identity information, but must also have the means to reach out to these identity repositories in an efficient and responsive manner. The Identity Microservice must also allow for both user-driven and server-to-server access to identity data.

The following diagram breaks down the components of the Identity Microservice:

The Identity Microservice at its core is made up of four layers:

  1. oAuth Authorization Server
  2. OpenID Connect UserInfo Endpoint
  3. Federated Identity Service from applications like Radiant Logic’s FID
  4. The server and web application clients of the Identity Microservice

Each of these layers performs a crucial role in securing access to identity data and also allows the microservice to obtain identity data from the required repositories. Breaking this down further:

  • The oAuth Authorization Server provides secure access to the Identity Microservices
  • The UserInfo Endpoint handles the requests for identity data and returns the requested profile information (claims)
  • The Federated Identity Service provides a centralized hub for obtaining application-specific profile data from directories, applications, databases and other microservices
  • Additionally, the Federated Identity Service needs to be able to aggregate and correlate profile data and leverage a real-time cache to ensure that access to profile data performs quickly and within the required application service levels

Today, the Identity Microservice’s components are based upon open standards and are both lightweight and highly leveraged by web applications and servers.

There are two main client flows supported by the microservice:

  1. User-driven Web Application flow
  2. Server-driven flow

Each of these flows require a different means of interacting with the Identity Microservice.

User-Driven Web Application Flow

Identity is at the core of nearly all web applications - everything from the initial authentication and authorization through to personalization with profile data. When logging into your banking application you not only need to securely identify you as the user, but also must authorize access to your accounts and personalize the site for your profile. Would you trust a banking application that listed your identity as “User”?

The following diagram breaks down the user-driven Web Application flow:

  1. User accesses the Web Application
  2. The Web Application redirects user to the Identity Microservice’s Authorization Server with a client ID and application scope
  3. User authenticates and authorizes request
  4. Authorization Server redirects user back to the Web Application with an authorization code
  5. The Web Application sends the authorization code to the Authorization Server with its client secret
  6. The Authorization Server returns an access token and ID token
  7. The Web Application sends the access token to the Identity Microservice’s UserInfo endpoint
  8. The Identity Microservice’s Federated Identity Service matches the application scope to the defined view and returns requested attributes
  9. The Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Web Application

There are several key factors in this flow:

  1. The scope sent to the Identity Microservice is the application, or view, for the requested profile data
  2. The view defined in the Federated Identity Service is application-specific and can be limited to just the profile data needed for the authorized application
  3. Multiple application-specific views can be supported by the Identity Microservice
  4. Authentication can be easily mapped back to the user’s profile repository by the Federated Identity Service allowing client web applications to completely delegate authentication to the microservice

 

Server-Driven Flow

While similar to the user-driven Web Application flow, no user interaction is present for this transaction. The Server-driven flow allows for backend access to profile data. In this case, the server is being authenticated and not the user.

The following diagram breaks down the Server-driven flow:

  1. Server sends client credentials and application scope to the Authorization Server
  2. Authorization Server returns an access token and ID token
  3. Server sends the access token to the UserInfo endpoint
  4. Federated Identity Service matches the application scope to the defined view and returns requested attributes
  5. Authorization Server returns the requested user information (claims) from the UserInfo endpoint to the Server

This allows the server to access the same profile data as defined for a Web Application. Additionally, the same views in the Federated Identity Service can be leveraged, if desired, for both Servers and Web Applications.

The Identity Microservice allows for powerful, yet lightweight access to all the needed profile data in an efficient manner. This microservice can provide what is needed at the core of all applications, and for the Server-driven flow can even be used for transaction-specific data unrelated to users. As the world moves toward the model of easily consumable services, the Identity Microservice must be one of the main considerations when designing an application.

Extend CA Single Sign-On with Axiomatics!

Two decades in the Identity & Access Management space has exposed us to our fair share of “where did we go wrong?” scenarios - organizations that thought they were following best practices and ended up creating problems for themselves over time.  One especially problematic area has to do with role management and traditional RBAC (role-based access control). Often, organizations start off with the best intentions and establish just a few roles:

  • Admin
  • Employee
  • Customer
  • Partner

The roles become more granular over time:

Admin Employee Customer Partner
SuperAdmin Employee - HR Customer - Platinum Support Partner - Support
RegularAdmin Employee - IT Customer - Gold Support Partner - Implementation
LightAdmin Employee - Sales Customer - Trial Partner - Temp
AdminTemp Employee - Support Customer - Temp Partner - Marketing

Before you know it, that “handful” of roles you started with has expanded into a tangled web, creating an administrative burden and taxing the systems whose rules rely upon them. CoreBlox has seen environments that have over 15,000 roles! In the IAM industry this is generally referred to as the dreaded “role proliferation” (cue Darth Vadar theme).

Fortunately, there is a great alternative to RBAC. Our partner, Axiomatics, has pioneered the concept of Attribute-Based Access Control, also known as “ABAC”. The thought process behind ABAC is easy to understand: why create new data attributes to manage (e.g. Roles) when you can let the user data speak for itself?

Organizations that already use CA Single Sign-On for web access control have a distinct advantage when it comes to implementing an ABAC approach. The Axiomatics Extension for CA Single Sign-On allows policy decisions to be made by Axiomatics’ ABAC-based engine. A simple yes/no response is returned to CA SSO based upon the user’s attributes. It just works, no coding necessary!

Are you interested in exploring the benefits of ABAC for your organization? Download this new white paper: Making a Business Case for Attribute Based Access Control