Fan-Out Provisioning

The Principle

Define once. Apply everywhere. A single identity definition produces concrete access across all downstream systems, data stores, and source code repositories. Cloud platforms, identity providers, git repositories, SaaS applications, databases, storage buckets, anything with an API. The person is defined in one place. Automation provisions them across all systems.

The Scale of the Problem

A typical enterprise employee has accounts across thirty or more systems. In the traditional model, provisioning access across all of them means thirty tickets, or one ticket with thirty subtasks, handled by different administrators at different speeds. The result is days of partial access and a persistent uncertainty about whether everything is set up.

Git repository permissions and cloud platform permissions are especially tightly coupled. An engineer who can merge to the main branch should have corresponding cloud permissions to deploy. An engineer who loses cloud access should lose the ability to push to protected branches. When these systems are provisioned independently, they drift apart. Someone gets deploy access but no repository write access, or the reverse.

Fan-out provisioning addresses this. A single definition: a person, their team, their role: is the input. The output is coordinated provisioning across each system that role touches, simultaneously and consistently. Git and cloud permissions are provisioned together because they derive from the same definition.

The Mapping Layer

Between the abstract role and the concrete system sits a mapping layer. “Senior backend engineer on the payments team” is abstract. What that means in each downstream system is concrete and specific: a set of permissions in one cloud platform, write access to the payments source code repositories, read access to the payments database, membership in a code review group, a seat in a SaaS application.

The abstract definition is stable. The mappings evolve as systems are added, removed, or reconfigured. A person's assignment does not need to change because a new monitoring tool was adopted or a cloud account was restructured. The mapping layer absorbs that complexity.

Portability Through Abstraction

The mapping layer is also the portability layer. Because the identity model is defined in abstract, vendor-neutral terms, concrete integrations translate that model into system-specific actions. The model reflects the organization's structure: teams, roles, policies. The integrations are pluggable: added, removed, or replaced without restructuring the model.

Organizations change their tools. Identity providers are replaced. Cloud platforms are adopted and retired. SaaS applications come and go. If the access model were coupled to a specific vendor's data structures, each tool change would require rebuilding the model. Because it is abstract, tool changes require only adding or modifying an integration.

Adopting a new platform: a new cloud provider, a new monitoring tool, a new collaboration service: is an integration task, not a model redesign. A new mapping translates existing roles into the new platform's permission model, and each current assignment automatically extends to the new system. The cost of switching vendors is bounded by the integration layer. The model: which represents years of organizational knowledge about roles, teams, and policies: is preserved.

Antipatterns

• Each system is provisioned independently through separate tickets.
• Adding a new tool requires restructuring the identity model.
• Replacing an identity provider means rebuilding role definitions from scratch.
• Access is defined differently in each downstream system.