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.

Contractors illustrate the problem at its most concrete. A vendor engineer who needs access to three systems for a specific project receives three separate grants, each through a different process, each with a different expiration mechanism (or none). The project manager assumes the contractor's access is scoped to the project. The system administrators see only the individual grants, not the business context that bounds them. When the project ends, revocation depends on someone remembering that the grants existed and which systems they span. Contractors are not edge cases. Organizations of any size have a long tail of external collaborators, auditors, consultants, and vendor support personnel, each with grants that were provisioned independently and will be revoked inconsistently.

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.

This is where the hard engineering work lives. Each downstream system has its own permission model, API semantics, rate limits, and error behavior. Writing an integration is not a trivial translation task; it is an engineering effort that requires understanding both the abstract model and the target system. The value of the abstraction is that this work is done once per system, not once per person.

Protocols like SCIM (System for Cross-domain Identity Management) exemplify what the mapping layer speaks downstream. SCIM standardizes user and group CRUD across applications via a REST API. A SaaS application that supports SCIM becomes a simpler integration target: the mapping layer issues standard operations rather than custom API calls. But SCIM addresses user and group lifecycle, not role definitions, approval workflows, or temporal constraints. It is a transport within the mapping layer, not a replacement for the abstraction above it.

Other transports serve different targets. Terraform and Pulumi providers can implement the mapping layer directly: the desired state becomes a Terraform plan, and terraform apply fans out to downstream systems. This is how many organizations would actually build integrations — the terraform plan versus terraform apply distinction maps directly onto the dry-run versus execute pattern described in Factor VI. SAML and OIDC handle authentication and federation upstream of the mapping layer; they tell you who someone is, not what they can do. Custom REST APIs cover the majority of downstream targets that speak no standard protocol at all. The mapping layer writes bespoke integrations for these, and this is where most of the engineering effort goes. The value of the abstraction is that each of these transports is written once per system, not once per person.

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.

Acquisitions stress this abstraction in a different direction. The acquired company's systems become new integration targets overnight. Their employees become new people in the model. Their roles, which made sense in their organizational context, must be expressed in terms of the combined organization's access model. The abstraction layer is what makes this tractable: the acquired company's systems are new mappings, their roles are new definitions, and their people are new assignments. The model scales to absorb them because it does not assume that all systems share a single permission schema or that all people share a single employment relationship.

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.
• Contractor access is granted system-by-system with no unified provisioning or revocation.
• An acquisition adds new systems but the access model is not extended to cover them.