Identity as a Microservice



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.

CA Access Gateway Install Error: "JRE libraries are missing or not compatible"


We ran into a problem during a recent installation of CA Access Gateway 12.6 (formerly known as CA Secure Proxy Server) on Red Hat Linux, and would like to share the solution. 

Upon launching the installer, the following error was displayed:  "JRE libraries are missing or not compatible..."


This may have to do with insufficient permissions in the /tmp directory.  In environments where obtaining the required permissions may not be straightforward due to how the server is locked down, security policies, etc., there is a simple workaround.

You need to create a new "temp" directory in a location where you do have the proper permissions (for example, /opt/myapplication/tmp), and then set an environment variable called "IATEMPDIR".  Example:

mkdir /opt/myapplication/tmp

export IATEMPDIR=/opt/myapplication/tmp

You should not be able to successfully launch the installer without encountering the "JRE libraries are missing or not compatible" error.

Good luck!

Virtualize SailPoint IdentityIQ's Database with RadiantOne!

CoreBlox Senior Architect Anthony Hammonds recently participated in our partner Radiant Logic's webinar focused on how to virtualize SailPoint IdentityIQ's database with RadiantOne such that it can be easily extended for use with LDAP applications, WAM systems, and Federation. The webinar playback and presentation can be found on Radiant Logic's web site:

As always, please contact us if you have any questions about Radiant Logic or SailPoint solutions!