Skip to main content
Identity Authority
Category: User Provisioning

Source System

Also known as: Authoritative Source, System of Record (related concept)
Simply put

A source system is any system, application, or file that holds data of interest and serves as the origin from which that data is collected or fed into other systems. In identity contexts, it is typically the system where identity information such as employee or user records originates before being synchronized elsewhere. For example, an organization such as a bank may operate many source systems that each capture and maintain different sets of data.

Formal definition

In IAM and IGA deployments, a source system is an operational system, database, file, API, or service that captures or maintains data used as an input to identity lifecycle processes such as provisioning and reconciliation. It is commonly the origin from which identity attributes are read and propagated to downstream targets, and in many deployments a specific source system is designated as the authoritative source for particular attributes. The term describes the data-origin role in a data flow and should be distinguished from a system of record (the definitive holder of a record) and a source of truth (an information system that aggregates or harmonizes data from multiple sources); depending on architecture and configuration, a single system may or may not play more than one of these roles. Note that whether a source system participates in runtime access enforcement versus lifecycle administration depends on deployment; as used here the term refers to the data-collection and provisioning input role rather than to runtime enforcement components such as a PDP or PEP.

Why it matters

In identity governance and administration, the source system is the origin point for identity data, which means the quality and timeliness of everything downstream depends on it. If a source system captures inaccurate, stale, or incomplete records, those defects propagate into provisioning, reconciliation, and access decisions across every target the data feeds. Designating which system is authoritative for which attributes is therefore a foundational architectural decision: when the authoritative source for an attribute is ambiguous or contested, organizations risk conflicting data, orphaned accounts, and access that persists after it should have been revoked.

The distinction between a source system, a system of record, and a source of truth matters because these roles are frequently conflated in practice, yet they describe different responsibilities in a data flow. A source system is the data-origin role from which attributes are read and propagated; a system of record is the definitive holder of a record; and a source of truth is an information system that aggregates or harmonizes data flows from different sources. Depending on architecture and configuration, a single system may or may not play more than one of these roles. Treating them as interchangeable can lead to design errors, such as trusting an aggregating source of truth as if it were the authoritative origin for an attribute it merely harmonizes.

Because organizations such as a bank may operate many source systems that each capture and maintain different sets of data, governance teams must map which system owns which attributes before automating identity lifecycle processes. Without that mapping, access reviews and certifications may be conducted against data whose provenance is unclear, undermining the assurance those controls are meant to provide.

Who it's relevant to

IAM and IGA engineers
Engineers configuring provisioning and reconciliation must identify which source systems feed identity attributes and how those flows are mapped to downstream targets. Correctly designating authoritative sources for specific attributes is central to avoiding data conflicts and ensuring lifecycle automation behaves predictably.
Identity governance leads
Governance teams rely on accurate source-system data to conduct access reviews and certifications. Understanding the provenance of each attribute, and distinguishing a source system from a system of record or a source of truth, is necessary to trust the data underpinning these controls.
Security architects
Architects designing identity data flows decide which systems serve as authoritative sources for which attributes and how those roles map across the environment. In organizations operating many source systems, this mapping shapes both data integrity and the boundaries between lifecycle administration and runtime enforcement.
Data and integration engineers
Because source systems can include operational systems, databases, files, external APIs, and web services, integration engineers responsible for collecting and feeding data into identity platforms need clarity on each system's role in the data flow to build reliable pipelines.

Inside Source System

Authoritative Data
The identity attributes and records for which the source system is considered the system of record, such as employee data in an HR system or student data in a student information system. Downstream systems typically treat these values as canonical.
Identity Records
The core representations of principals (for example, workers, contractors, or students) that originate in the source system and are propagated outward, often serving as the trigger for downstream account creation.
Attributes and Profile Data
Fields such as name, employee ID, department, job title, manager, and status that the source system exposes to consuming systems. Which attributes are authoritative depends on the deployment and integration design.
Lifecycle Events
State changes such as hire, transfer, role change, leave, and termination that the source system emits or reflects, driving joiner-mover-leaver processes in downstream provisioning. These are IGA lifecycle concerns rather than runtime access enforcement.
Integration Interface
The mechanism by which the source system is consumed, which may include SCIM endpoints, LDAP directory reads, database connectors, flat-file exports, or vendor-specific APIs, depending on configuration.

Common questions

Answers to the questions practitioners most commonly ask about Source System.

Is the source system the same thing as the identity provider (IdP)?
No, though they are sometimes co-located. In IGA contexts, a source system (often called an authoritative source or system of record) is where identity data originates and is mastered, commonly an HR system for worker records. An identity provider is a runtime authentication component that asserts a principal's identity to relying parties, typically via protocols such as SAML 2.0 or OpenID Connect. A source system feeds identity data into downstream systems (frequently including the IdP's underlying directory), but it does not itself perform authentication. Conflating the two blurs the distinction between where identity data is governed and where authentication is enforced at runtime. Note that in some deployments a single platform plays both roles, so verify the specific architecture rather than assuming.
Does designating a source system as authoritative mean it controls what users can access?
No. Being authoritative means the system is the trusted origin and master for specific identity attributes (for example, employment status, department, or manager), not that it makes access decisions. Authorization, determining what a principal may do, is handled separately, typically by policy and enforcement components (PDP/PEP) at runtime, or granted through provisioning workflows in IGA. A source system may supply attributes that those decisions consume (for instance, feeding an attribute-based or role-based model), but supplying an attribute is distinct from evaluating a policy. Keeping the authoritative-source role separate from access enforcement avoids blurring identity data governance with runtime authorization.
How do you decide which system should be authoritative for a given attribute?
In most deployments authority is assigned per attribute rather than per system, because different systems master different data. An HR system is commonly authoritative for worker lifecycle attributes such as hire date, status, and organizational unit, while a badging or telephony system might be authoritative for other attributes. The general approach is to identify, for each attribute, the system where that data is created and maintained with the highest accuracy and appropriate ownership, then document that mapping. Where multiple candidate systems exist, precedence rules resolve conflicts. The exact assignment depends on your organization's processes and data ownership.
How is identity data typically brought in from a source system?
This varies by system and vendor. Common patterns include scheduled or event-driven imports via connectors, database or file-based feeds (such as flat-file or CSV extracts), API-based reads, and directory reads over LDAP where the source is a directory. For downstream propagation of the resulting identities, SCIM is frequently used for provisioning to target applications. The ingestion mechanism and its frequency (batch versus near-real-time) depend on the source system's capabilities and the timeliness your governance processes require.
What happens when the same attribute appears in more than one source system?
You generally need a precedence or reconciliation strategy so the platform can resolve conflicting values deterministically. Typical approaches include ranking sources so a designated authoritative source wins for a given attribute, or applying attribute-level precedence where different sources take priority for different fields. Reconciliation and correlation logic also matter for matching records that represent the same person across systems. The specific behavior depends on the platform's configuration, so define and document these rules explicitly rather than relying on defaults.
How does source system data relate to the joiner-mover-leaver lifecycle?
In many IGA deployments, changes detected in an authoritative source drive lifecycle events. A new record can trigger provisioning (joiner), an attribute change such as a department or manager update can trigger access recalculation (mover), and a status change to terminated can trigger deprovisioning (leaver). This ties governance and administration processes to trusted source data. Note that these are lifecycle and provisioning actions, which are distinct from runtime access enforcement; the source system informs what should be provisioned, while enforcement of active sessions and access is handled separately. Exact triggers and timing depend on configuration.

Common misconceptions

The source system and the identity provider (IdP) are the same thing.
A source system is typically an authoritative source of identity data (such as an HR system) that feeds provisioning, while an IdP is a runtime component that authenticates principals and issues tokens or assertions. In many deployments these are separate systems, though a single product can play both roles depending on configuration.
Being the source system means the system controls what users are authorized to do.
A source system supplies authoritative identity and attribute data; it does not by itself perform authorization. Authorization decisions are typically made at runtime by policy decision and enforcement points using models such as RBAC or ABAC, which may consume attributes originating from the source but are distinct from it.
There is always a single source system for all identity attributes.
Different attributes can have different authoritative sources; for example, HR may be authoritative for employment status while another system is authoritative for a particular entitlement or phone number. In most deployments the authoritative source is defined per attribute rather than globally.

Best practices

Define authority at the attribute level, documenting which system is authoritative for each attribute rather than assuming one global source of truth.
Treat source-system-driven provisioning as an IGA lifecycle concern, mapping joiner-mover-leaver events to downstream account creation, modification, and deprovisioning.
Standardize integration on interoperable mechanisms such as SCIM or well-defined connectors where feasible, and document the interface, sync frequency, and error-handling behavior for each consuming system.
Keep identity data flow separate from runtime authorization, ensuring attributes sourced for provisioning are validated before being relied upon by policy decision points.
Establish reconciliation and access review processes to detect drift between the source system and downstream targets, since propagation delays and failures vary by deployment.
Validate data quality at ingestion, since inaccurate or stale source data typically propagates into every downstream system and can undermine both provisioning and later access certification.
Promotional banner for the Pentest Readiness checklist download