Why Centralized Identity Management is important and how to get there - PART II

In the previous part, we have reviewed the consequences, challenges, and lost opportunities of having multiple identity solutions for your enterprise applications or products. In upcoming parts, I will take you through our journey to achieve centralized identity management.

What you will learn in this part

Various exercises that we performed to take the first step towards centralized identity management.

1. Build a catalogue of applications to understand how your custom identity solutions are used across various applications to know the impact of radar.
2. Compare home-grown identity solutions against Industry Open Standards for Authentication and Authorization.
3. Get introduced to the some of the leading Customer Identity and Access Management (CIAM) solutions in the market.

Build an application catalogue

Until then, we didn’t have one single view of the ecosystem of our applications. We considered this to be a very good opportunity for us to build and maintain the catalogue for general purposes such as auditing, manage life cycle, costs, maturity level etc.

We have built the application catalogue with the below information:

• Product Family
• Application Name
• Application Type (web app, API, native, SPA)
• Identity Type - user or machine, or both
• AuthN/AuthZ Solution - AD, Forms Authentication, Custom Identity Solution
• Regulatory Compliance - audit against the data protection regulations such as GDPR

You can also add more information such as vulnerability level, purpose etc which will eventually bring more clarity around the need of using standard solutions.

Assess against Open Standards

We spent time learning the various standards mentioned in Part I. As a result, we picked OAuth and OpenID Connect standards as the go-to standards to be adopted for our centralized identity management solution (based on their support for the latest technologies and a wide range of devices).

Then, we assessed our home-grown solutions (or other ready-made solutions) whether they support the following standards and parameters.

There are some cool articles which help explain the standards. I have listed some of them here and highly recommend starting with these:

• https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect
• https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc

It is important to at least have a beginner level of knowledge on OAuth 2.0 and OpenID Connect before proceeding. The above articles would provide a good starting point.

OAuth 2.0 - Authorization

A Quick Overview - OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

Protecting resource:

• Does it provide the ability to restrict the scope for an application towards accessing the protected resources?
  • E.g. inventory API consist of actions such as List, Get, Update, Delete of a particular product.
  • Either one or all actions can be considered as being within the 'protected scope of a resource'.
  • An application can be configured to access reading scopes such as List and Get.
• Does it help protected resources from having unauthorized access?
  • E.g. can an Inventory API validate the access for every request before executing the action?

Support for all application kinds

• Trusted or confidential applications - typically run from your data centres or known vendor's data centre which consumes your solution.
• Non-trusted or public applications - typically run from consumers' environment such as browser or desktop (Native).

Support for various user flows

Does your solution:

• Have the ability to identify whether the authentication was triggered by a machine?
• Have the ability to identify whether the authentication was triggered by a human?
• Have the ability to identify whether the authentication was triggered on-behalf-of a user?

OpenID Connect - Authentication & Authorization

A Quick Overview - OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the end-user based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. 

Where does your solution stand in terms of:

• Managing the clients (consuming applications) dynamically
• Allowing the clients to dynamically discover the information such as available scopes, supported claims, and supported application kind & user flow?
• Managing the sessions and their configuration per client
• Achieving internal and external (federated) SSO
• Delegated administration of users
• Provisioning RBAC for applications
• Managing APIs and their access control

Introduction to commercial CIAM solutions off the market

The above assessment will yield either one of the following results

1. None of your solutions match the specification of Open Standards OR
2. One or more solutions could meet the standards

Irrespective of the result, you will still have to fulfil the original aim, i.e., centralizing identity management. That means all the applications must use only one system to get the benefit of centralized identity management, which was explained in Part I of this blog.

Let’s say that you have found a suitable solution candidate, but as a matured enterprise, you will have to take the important decision of ‘Build/Maintain vs Buy’. Yes, you have heard it and it is very critical to decide on behalf of your organization.

To decide between build/maintain and buy, you must explore the answers to the following questions on behalf of your organization

• Is your organization ready to spend energy and resources on this solution in the long-term?
• Do you have a dedicated team to maintain? Maintenance includes language framework upgrades, Open Standards upgrades, Infrastructure, Support, Knowledge Base, etc.
• Does this solution have enough knowledge base to start with? If not, do you have experts to build one?
• Does this solution provide the required toolkit such as authentication libraries, migration tools etc? If not, do you wish to put the effort into building those? Do you have experts for that?

The answers to the above questions will vary between organizations. But they will pose further questions. Importantly one question will stand out.

Are there equivalent solutions in the industry so that you can realize the value of your solution candidate?

This leads to a hunt in finding the best solutions in the market. They are generally called Customer Identity and Access Management (CIAM) technology solutions.

Create a shortlist

There are several solutions (approx. 25 of them) in the market. You can’t go and spend your valuable time comparing all of them. You will have to create a shortlist based on your initial criteria. But how do you shortlist for your assessment? What parameters are you going to use to bring the numbers down?

One thing to remember is that all the CIAM solutions lead to the same benefits. But it is critical to determine how efficiently we get there.

The following questions stood out and helped us to complete the handpick

• Who are the main actors in this exercise (Centralizing Identity Management)? - Developers
• Should your solution have marketing analytics such as cross-marketing capabilities and business intelligence activities? - No, because we had our way to identify those.
• Do you expect your solution to be part of the primary development ecosystem like PaaS or IaaS? - Yes
• Should your solution replace existing Employee IAM? - No, because we have Azure AD

As an outcome, we had shortlisted the following options

Microsoft AD B2C Auth0 Okta

To be continued

In Part 3, we will see the selection criteria to conclude on the suitable solution for your need.

Author: Natarajan Sennappan