Directories and identity providers are not the same as workforce source systems or local application account stores, and confusing them creates brittle synchronization and weak ownership.
Identity stores and directories are the systems that hold, synchronize, and expose identity data for lookup, authentication, and policy use. They are central to IAM, but they are not the whole identity landscape. A workforce system, a partner directory, an identity provider, and an application’s local account store may all participate in one access model. Confusing those layers creates brittle synchronization, duplicate identities, and false assumptions about what system is truly authoritative.
This topic matters because many IAM problems begin with the sentence “the directory says so.” The directory may indeed hold a value, but that does not automatically make it the original source of truth. If an employment status comes from HR, an application owner comes from an internal service catalog, and a customer membership comes from the product itself, then the directory is aggregating facts from multiple systems. The architecture must respect that distinction.
When organizations collapse all identity layers into one mental model, they usually create one of two failures:
The result is inconsistent access. A user leaves the company but still exists in a SaaS tool because local accounts were never tied back to workforce lifecycle. A contractor’s sponsorship changes in the vendor system but the directory still shows active group membership. A customer record becomes suspended in the product but its external admin identity remains live in a separate tenant store. These are not edge cases. They are common architecture failures.
The diagram below shows the basic relationship between source systems, directories, identity providers, and local stores.
flowchart LR
A["Source systems (HR, vendor, product, CMDB)"] --> B["Directory or identity graph"]
B --> C["Identity provider"]
B --> D["Governance and policy inputs"]
C --> E["Applications and SaaS"]
F["Local app account store"] --> E
A --> F
What to notice:
These systems originate facts about an identity. For workforce identities, that may be HR or contractor onboarding. For customer identities, it may be the product’s tenant membership model. For machine identities, it may be a platform catalog or infrastructure inventory. Source systems answer questions like:
Directories organize and expose identity objects, groups, and attributes in a way that other systems can consume. They are useful because they centralize lookup and often support authentication flows or policy queries. But directories may be downstream of more authoritative sources for many attributes.
Identity providers handle authentication and federation. They issue sessions, assertions, or tokens to applications and platforms. They often rely on a directory or graph, but their role is not identical to the role of a source system. An identity provider can confirm an identity successfully while still relying on upstream systems for lifecycle meaning.
Many applications still keep local users, local roles, or tenant-specific identities. That is not automatically wrong. Local identity can be legitimate for product-specific authorization or customer-admin workflows. The risk appears when local stores become disconnected from central lifecycle and review, or when teams assume SSO alone solved everything.
The YAML below shows a simple architecture map that distinguishes origin, directory, and consuming systems.
1identity_data_model:
2 workforce_status:
3 source: hr-system
4 replicated_to:
5 - workforce-directory
6 - identity-provider
7 contractor_sponsor:
8 source: vendor-onboarding
9 replicated_to:
10 - workforce-directory
11 customer_tenant_membership:
12 source: product-tenant-store
13 replicated_to:
14 - customer-identity-provider
15 privileged_admin_eligibility:
16 source: access-governance-system
17 replicated_to:
18 - identity-provider
19 - pam-platform
The value of the example is not the syntax. It is the distinction:
This makes architecture reviews more honest. If a team asks, “Why did this account stay active?” the answer can be traced to the originating system and the synchronization path instead of being blamed generically on “identity.”
Identity stores create risk when synchronization logic is unclear or slow. Common problems include:
These issues are especially visible in hybrid environments and in older applications with local account models. The right question is not whether centralization is perfect. The right question is whether the architecture clearly defines authority, propagation, and cleanup for each important identity fact.
An enterprise says its central identity provider is the source of truth for workforce, partner, and customer identity because every major application uses it for sign-in. However, HR status, contractor end dates, and customer tenant membership all originate elsewhere and do not always synchronize cleanly. Is the identity provider truly the source of truth?
Not by itself. It is a central access component, but the authoritative sources are still distributed. The stronger design names those sources explicitly, documents replication paths, and treats the identity provider as a consumer and issuer of trust, not as the origin of every identity fact.
SC-900 • cloud IAM fundamentals • enterprise architecture and identity governance learning paths
This lesson prepares the ground for federation, lifecycle, governance, and product authorization. Clean source-of-truth thinking is what keeps later automation from becoming brittle.