“Identity Fabric Immunity (IFI) cannot be compared with traditional IAM; rather, it describes an ideal state an organization can reach by using disparate IAM approaches and the best available identity services that enable the building of a cohesive identity fabric,” says Mark Callahan, senior director of product marketing at Strata.io.

“An identity fabric immunity is not a product but the result of implementing identity orchestration software that allows the organization to create an identity fabric that integrates its existing and incompatible IAM solutions and products.”

How identity fabric immunity is implemented

Here are some key roles in an IFI implementation:

• IdP (identity provider): There must be a central directory of record for auth services to the various functions in the IFI, and this is it. It may be a datastore such as lightweight directory access protocol (LDAP) or a cloud IAM. When moving towards IFI, some credentials may be migrated from standalone data stores.
• API gateway: This component facilitates secure communication between applications and the identity fabric. It is the network routing aspect providing a central point of orchestration and security for the various apps and services.
• Identity broker (IB): A kind of facade that makes it simpler for client components to talk to negotiate authentication. It is a component dedicated to facilitating the initial authentication interactions between ID consumers and providers.
• Policy engine: This component defines the authorization rules based on user roles, attributes, and context (e.g., location, device). Along with the ID broker, provides a high-level abstraction to smooth out infrastructure irregularities.

In general, IFI moves towards consistent, centrally manageable answers to the questions: How does an app authenticate and authorize? How do you provision and interact with an API? How do you create and revoke credentials?

Bringing these answers into a consistent framework means reduced attack surface and fewer worrisome mysteries in a system. The larger the enterprise, the more difficult it is to bring these into alignment, and it’s useful to think about things in a staged or maturity model.

When conventional IAM fails, IFI is a compelling answer

In a conventional identity management model, the various apps and services that comprise business operations rely directly on particular data stores for their credentials. The interactions and networking that support them are often one-off solutions born out of the specific needs of the application in development at the time.

The reality of the modern enterprise is that it often includes a spectrum that spans legacy and modern cloud services and everything in between. Sometimes what might be derided as legacy is a valuable business process that works well, save for the difficulty in managing and integrating its security processes.

Sometimes on-prem, private-cloud, or cross-provider deployments are demanded by compliance or other considerations. The bottom line is that this kind of infrastructure and process complexity is here to stay and yet security demands uniformity and control with equal insistence.

“A CSO who is modernizing applications and identities for the cloud while struggling with legacy IAM technical debt should consider building an identity fabric,” says Callahan. “A key flag indicator for implementing IFI occurs when a company is struggling to manage identities in multiple identity providers in multiple clouds and in hybrid clouds (on-premises IDP and cloud-based IDP).”

An identity fabric immunity scenario

To help visualize the concept, consider a scenario where there is a backend — it could be Java, .NET, NodeJS or something else, the particular stack isn’t important – that exposes APIs and implements business logic. It talks to a datastore somewhere and security-wise accepts credentials (probably username/password) and validates them.

Once that is successful, some kind of token is added to the user session. The token could be handled in a number of ways, such as through a cookie or request header. The backend component would require something like the following to move into an IFI setup:

• Put it behind an API gateway. Client requests are now sent to the API gateway, which is responsible for authentication and potentially for authorization as well.
• Host user credentials on an independent identity provider. This could be handled in two basic ways: migrate the existing credentials to the IdP or require users to re-register on the new IdP
• The API gateway now communicates with the IdP to propose user credentials and receive an authorization token, likely a JWT (JSON web token) and preferably via a standard protocol like OIDC.
• Once the user is authenticated, further requests are judged by their token. A token like JWT can hold user claims like roles, and on that information authorization processing can happen with the API gateway and IdP. This implies more modifications of the existing application.

Other components can be seen as variations on this. For example, there may be a JavaScript frontend that talks to this backend. It would now point to the API gateway and deal with the negotiation of authentication (and possibly authorization) using the new token-based mechanism. Microservice components that already use an API gateway are more readily migrated, depending on their existing authentication process.

Every secured component in the landscape can come under the fabric, however, some elements of the enterprise are more difficult to manage for reasons beyond technology required, such as development processes like build tooling, continuous integration, and hosting access to virtual machines, PaaS, and serverless.

While IFI is designed to directly address the end-user access to these (the employees, partners, and customers using them), the behind-the-scenes access that developers use themselves can prove trickier because of their unique tools and need for agility.

“Before anything can be done, CSOs must make their case to company leadership for approval, explaining that an investment in IFI serves as a business enabler and a critical path to contain business risks,” Sotnikov says.

The idea of an identity fabric will continue to grow in importance in the coming years. It requires a significant investment of time and money, but fortunately can be approached in incremental stages as the need justifies itself to the business.

More on identity management: