The Inspiration
His hands descended, transitioning from palms-down to palms-up, as though cradling a ball. “We want to use the cloud to bring everything together and manage it in one place.” he explained through translators.
Over the next weeks and months, I would come to understand this recurring gesture that expressed his clear and simple vision:
“We aim to maintain a centralized user view for HR and administrative purposes. Ideally, we want to manage the entire set of users within a central cloud directory while still allowing local administrators to make changes in their respective disconnected ADs or Azure ADs.”
Director, Identity and Access Management, Global Conglomerate, October 2016
Organizational unity with subsidiary autonomy. This Global 500 company pursued a goal that wasn’t attainable using Microsoft Identity back then… or now. The Identity Bridge started as a thought experiment in 2016, sparked by two fundamental questions leading to two inevitable conclusions:
1. Customer: If the cloud is supposed to simplify IT, why do we force organizations to perform the most complex IT exercise they have ever attempted to start using the cloud?
We should not. We should simplify the customer journey rather than complicating it. We should provide simple tools for complex organizations.
2. Technology: If Azure Active Directory is the heart of the Microsoft cloud, why do we insist on network line-of-sight between all customer directories trying to connect to it?
We should not. We should use the near-instantaneous connectivity of the Internet backbone to connect the disconnected parts into a cohesive whole.
Design Principles
Many large organizations have users provisioned across directories (Azure AD and others). This creates collaboration, administration, and governance challenges. To address the collaboration challenge, Identity Bridge provides a simple, reliable, high-performance sync engine built on these principles:
- Decoupled: Independent readers and writers communicate to a central service bus to efficiently handle mesh topologies.
- Parallel: Per tenant readers and writers enable parallel processing.
- Streamlined: No intermediate storage along the sync path improves resilience and allows sync performance to approach machine speeds.
- Transparent: A single pane of glass across tenants and sovereign clouds provides unified, real-time, and persistent visibility for monitoring and forensics.
Decoupled
Azure Service Bus enables a decoupled, scalable, publish-subscribe model to bridge readers and writers. Reader and writer interaction with a shared service bus simplifies the system. A service bus-based system grows linearly with more tenants. A point-to-point system (e.g. Microsoft’s tenant-to-tenant sync) grows as the square of the number of tenants. Let’s illustrate the difference.
Point to Point Model: Imagine you need to connect two points. Connecting them requires one line. Add a point. You now need 3 lines. A fourth point? 6 lines. The number of lines needed to connect all the points grows as the square of the number of points.
Service Bus Model: Now imagine a central point (a service bus) that connects all the points. The number of lines now grows linearly with the number of points.
In practical terms, adding a tenant to a service bus-based sync configuration requires configuring that tenant and a single data path versus reconfiguring n tenants and creating n new data paths.
Parallel
Azure Functions provide scalable, parallel access to an unlimited number of Azure AD tenants. So not only do the number of read and write connections scale linearly with (rather than with the square of) the number of tenants, but each reader and writer operates in parallel.
Streamlined
No cloud service is perfect. However, a sync engine running every few minutes in perpetuity must take as few dependencies on other systems as possible to minimize outages and maximize uptime. Removing all synchronous storage calls from the sync path improves resilience while allowing sync performance to approach machine speeds.
Transparent
The Azure SignalR Service helps to provide real-time insight into synchronization progress. Configuration data and audit logs are kept in Cosmos DB. Provisioning logs are kept in Azure Blob Storage.
Wrap Up
What started as a thought experiment of the simplest possible solution to the problems of a complex organization has become the Identity Bridge. This post describes the inspiration and key design principles underlying its backend design. Next week, we light this candle in a quickfire challenge. If this is at all interesting to you, please feel free to reach out with comments, criticisms, and/or requests.
