Identity Anti-patterns - Federation Silos and Spaghetti Identity

According to research conducted by the analyst firm, Quocirca, many businesses now have more external users than internal ones. Also many businesses are involved in acquisitions, mergers and partnerships, and these result in lots of external users joining the business. Often, these external users have to be integrated with the existing user base in bulk. This sort of integration can be complicated due to the different protocols followed by different identity systems.

How this impacts enterprise identity management

When working with both external and internal users and merging different systems together, you are faced with technicalities related to management of multiple heterogeneous user stores, different types of authentication protocols, legacy systems and many more.

SAML, OpenID, OpenID Connect, and WS-Federation all support identity federation and cross domain authentication. However, in a real world scenario, not all involved parties in a federation use case will support SAML, OpenID and OpenID Connect. Most of the federation systems seen today are in silos. It can be a silo of SAML federation, a silo of OpenID Connect federation or a silo of OpenID federation. While a system that uses SAML as it's protocol may be able to communicate with other SAML protocol-based systems, they may not be able to communicate with OpenID Connect or OpenID.

The diagram below illustrates how a silo of SAML federation, OpenID Connect federation and OpenID federation interacts within the respective silo and how it cannot interact with different silos.

Also consider the scalability of a specific federation silo. Within the SAML federation silo, for example, there can be an increasing number of service providers and identity providers. Each service provider has to trust each identity provider and this leads to the Spaghetti Identity anti-pattern. The following diagram depicts the complexity of this.