Identity fabric immunity is an approach to managing identity in a complex infrastructure environment like hybrid cloud or multicloud.
One eternal fact of life in software development is that complexity compounds. For the CISO, this truth is seen at work in the enterprise infrastructure — the number of components expands along with the sophistication and diversity of the platforms hosting them.
Security and compliance are greatly impacted by this, calling for some kind of broadly applicable security framework that doesn’t magnify complexity or impede developer momentum. Identity fabric immunity (IFI) is an attempt to answer that call.
From identity management to identity fabric
IFI begins as a way of thinking about the enterprise software landscape and its relationship with security. It is in the vein of zero-trust architecture, in that it offers a mental north star that can be used to pilot through the morass of complexity that is modern software.
IFI says: make a shared, distributed layer of security that covers the entire enterprise. Bake into this layer monitoring and governance. Make apps and services rely on the layer for authorization and authentication.
Another term for “identity fabric” is “converged identity”. They mean the same thing: extracting identity into an abstract layer. At the cost of extra up-front planning and configuration, this layer proposes to reduce attack opportunity, improve mitigation and response, and simplify identity and access controls even in the most intricate of circumstances.
Identity fabric versus traditional identity access management
The backdrop or thesis that IFI is responding to is that existing identity access management (IAM) solutions are insufficient. IAM grew out of the need to secure cloud-based applications and exists as another kind of cloud service on which other services rely to obtain authorization and authentication information.
This model works well to a degree, but when the digital enterprise spans many cloud providers and/or bridges between public, private, and on-premises deployments, it begins to break down. The reality is that multi- and hybrid-cloud deployments are a fact of life in modern development.
Hybrid infrastructure, where some components are hosted on-premises and some are hosted by cloud providers, is especially in need of an improved security model. That is because the more boundaries that must be crossed — the more interacting components there are — the more opportunity there is for attack and the potential for sensitive information or services to be compromised.
When is identity fabric immunity necessary?
An identity fabric becomes an attractive option when it is merited, but the adoption of it before it is really called for adds unnecessary complexity. The key is knowing the tipping point.
If it is doing the job with minimal friction, a simple identity provider framework is sufficient. When the infrastructural complexity begins to cause serious difficulty within the organization, the security abstraction layer described by IFI offers a way forward, says Dmitry Sotnikov, chief product officer at Cayosoft. “Applications are now highly distributed, and users, partners, and customers log into systems from wherever they are, leaving security teams without an easily defined network and physical boundary to protect.”
Signs that identity solutions are inadequate include difficulty in managing user access, account provisioning, and response to security incidents both real and simulated. Managers may find that it is very hard to gain an overhead perspective on the security disposition of an enterprise and taking actions that affect security as a whole is cumbersome or extremely challenging.
IFI offers a way to abstract identity when the constituent parts of the system are homogenous and decentralized. This state of affairs has been referred to as identity sprawl. Everyone from the CISO to the end user knows about identity sprawl. For the user, it’s annoying and dangerous. For the CSO, it’s a huge problem. The more distributed the elements of security, the more difficult it becomes to form a complete picture of them, manage them, identify and fix holes, and respond to incidents.
The benefits of identity fabric immunity
The “immunity” in IFI refers to an inherent resistance built into the fabric of the system. An integrated security layer creates a venue for implementing consistent policy, continuous monitoring, and centralized change management. In other words, the fabric gives a unified context to apply security principles.
An identity fabric looks to provide a layer on which other components can rely. This layer begins with the diversity of the infrastructure as an assumption and makes it as simple as possible for the components with differing profiles to partake in it.
Without a holistic approach like IFI, the CISO and their team are forever playing whack-a-mole with vulnerabilities and attackers. The chief benefit of IFI is it brings the security universe into a cohesive, addressable whole.
“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: