Category: Directory Services

User Repository

Also known as: Identity Store, User Store, Identity Repository

Simply put

A user repository is the data store where an identity system keeps records about the people (and sometimes machines or services) it manages, such as usernames, credentials, and profile attributes. When someone tries to sign in or access a resource, the system typically looks up their record here to help verify who they are and gather information about them. It is essentially the authoritative list of accounts and their associated data.

Formal definition

A user repository is a persistent data store that holds principal (user or service) identity records, including identifiers, authentication material or references to it, and profile attributes such as group or role memberships. It is commonly implemented as an LDAP directory, a relational or NoSQL database, or a cloud identity service, and may serve as an authoritative source or a synchronized copy depending on the deployment. In access flows it is typically consulted during identification and as an input to authentication, and it can also act as a source of attributes for authorization decisions (for example, as a Policy Information Point in policy-based enforcement); note that the repository stores identity data but does not by itself perform authentication or authorization logic. Provisioning and deprovisioning of records into the repository is generally an identity governance and administration concern (often handled via mechanisms such as SCIM), which is distinct from runtime lookup and enforcement. Specific schema, credential handling, and query behavior vary by vendor, product, and configuration.

Why it matters

The user repository is the foundational data layer that most identity and access flows depend on. Because it typically holds the authoritative records used during identification and as an input to authentication, its integrity, availability, and access controls directly shape the trustworthiness of everything built on top of it. If the repository is compromised, altered, or made unavailable, the effects cascade: legitimate users may be locked out, and attackers who manipulate records or credential material may be able to impersonate principals or escalate their access. The repository is also frequently a source of attributes that feed authorization decisions, so the accuracy of the data it holds affects not only who can sign in but what they are subsequently permitted to do.

Because the repository stores identity data but does not itself perform authentication or authorization logic, teams sometimes underinvest in protecting it relative to the enforcement components in front of it. That is a mistake: stale, duplicated, or orphaned records, weak protection of stored credential material, or inconsistent synchronization between an authoritative source and its copies can all undermine otherwise sound access controls. Governance practices such as timely provisioning and deprovisioning matter here, since the repository's contents determine whether departed users still have live accounts and whether attribute-driven decisions operate on current data.

Getting repository design right also has practical consequences for scale and consistency. In deployments with multiple repositories or synchronized copies, discrepancies between stores can produce confusing or contradictory access outcomes, and reconciling which store is authoritative is a recurring operational challenge. Clear ownership of the authoritative source, disciplined synchronization, and controlled query and write paths are typically what keep an identity system's data trustworthy over time.

Who it's relevant to

Security Architects

Architects decide where authoritative identity data lives, how many repositories exist, and how synchronized copies stay consistent. They must reason about the repository as a critical data layer whose availability and integrity underpin identification, authentication, and attribute-based authorization, while keeping it distinct from the enforcement components that consume its data.

IAM Engineers

Engineers implement and integrate the repository, whether an LDAP directory, a database, or a cloud identity service, and wire up the query paths used during identification and authentication. They also configure how attributes are surfaced to authorization decisions, and must account for vendor- and configuration-specific behavior in schema, credential handling, and lookups.

Identity Governance Leads

Governance leads own provisioning and deprovisioning of records, often through mechanisms such as SCIM, and are responsible for keeping the repository free of stale, orphaned, or duplicated accounts. This lifecycle work is distinct from runtime lookup and enforcement but directly determines the accuracy of the data those runtime processes rely on.

Compliance Officers

Compliance officers care about the repository as the authoritative record of accounts and their associated data, which is central to access reviews and demonstrating that departed users no longer hold live accounts. They also scrutinize how stored credential material and profile attributes are protected.

System Administrators

Administrators operate the repository day to day, managing availability, access controls on the store itself, and synchronization between an authoritative source and its copies. Discrepancies between multiple stores can produce inconsistent access outcomes, so reconciliation and controlled write paths are recurring operational responsibilities.

Inside User Repository

Identity records

The core entries representing principals (typically users, and in some deployments service accounts or devices), each with a unique identifier used during the identification step of an access flow.

Credential material

Stored authentication data such as password hashes, references to possession or inherence factors, or pointers to external credential verifiers. What is stored varies by deployment; a user repository may hold credentials directly or delegate verification to another system.

Attributes and profile data

Descriptive fields (for example name, email, group memberships, department) that can feed authorization decisions in ABAC or role assignments in RBAC. The repository stores these attributes but does not itself make access decisions.

Group and role associations

Relationships linking identities to groups or roles that other components consume for access control. The repository holds the assignments; enforcement happens elsewhere (for example at a PDP/PEP).

Access interface

A protocol or API through which systems read and write identity data, commonly LDAP for directory-style repositories and SCIM for provisioning operations, depending on the implementation.

Lifecycle state

Status information such as active, disabled, or deprovisioned that supports IGA processes like provisioning and access reviews, distinct from runtime authentication and authorization.

Common questions

Answers to the questions practitioners most commonly ask about User Repository.

Is a user repository the same thing as an authentication service?

No. A user repository stores identity records and their associated attributes and credential references, while authentication is the process of verifying a principal's claimed identity, typically by validating a presented credential against data held in the repository. The repository is a data store consulted during authentication; it is not itself the authentication mechanism. In many deployments the two are separate components, and a single authentication service may consult multiple repositories.

Does storing users in a repository mean the repository controls what those users can access?

Not inherently. Storage of identity and attribute data is distinct from authorization. A user repository may hold attributes, group memberships, or role assignments that an authorization system consumes, but the decision about what a principal may do is made by the access control logic (for example a PDP evaluating RBAC or ABAC policy), not by the repository itself. Depending on configuration, the repository often acts as a PIP supplying attributes to an authorization decision rather than making the decision.

Can a user repository serve as both an authentication data source and a provisioning target?

In most deployments, yes. A repository such as an LDAP directory can supply credential and attribute data consulted during authentication while also being a downstream target for provisioning, often via SCIM or vendor connectors from an IGA system. These roles are separable concerns, however: lifecycle operations like provisioning and deprovisioning are IGA functions, whereas runtime lookups during authentication are enforcement-time operations. Whether one repository fills both roles depends on the architecture.

What should a user repository store versus what belongs in a token?

A user repository typically holds the authoritative, persistent identity record and its attributes. A token such as an ID token or access token generally carries a subset of that data as claims for a specific session or authorization context. Tokens are usually short-lived and should carry only the claims a relying party needs, rather than mirroring the full repository record. Note that a signed token protects integrity but not confidentiality, so sensitive attributes placed in a self-contained token may be readable unless the token is also encrypted.

How do multiple user repositories get reconciled in a federated or multi-source environment?

Approaches vary by deployment. Some architectures designate one repository as authoritative for a given attribute and synchronize or provision copies elsewhere, commonly through IGA-driven flows or SCIM. Others use a virtual directory or identity aggregation layer to present a unified view without physically consolidating data. Reconciliation logic must define which source wins for each attribute and how conflicts and stale records are handled; the correct pattern depends on data ownership, latency tolerance, and governance requirements.

What are common considerations when connecting a user repository to authentication and authorization systems?

Practical considerations typically include how credentials are referenced versus stored, how attributes are exposed to a PIP for authorization decisions, connection security and access control to the repository itself, and how deprovisioning propagates so that removed accounts no longer resolve during authentication. Query performance and availability matter because the repository may be on the critical path for runtime lookups. Specific capabilities, supported protocols, and synchronization behavior vary by vendor and configuration and should be verified against the product in use.

Common misconceptions

A user repository authenticates users.

A user repository primarily stores identity records, attributes, and credential material. Authentication is the separate step of verifying a principal, which an authentication service performs using data from the repository; the repository itself does not decide who a user is.

A user repository enforces access control.

The repository holds attributes, group, and role assignments, but authorization decisions are made and enforced at runtime by components such as a PDP and PEP. Storing role or group data is not the same as evaluating or enforcing policy.

LDAP directory and user repository are synonyms.

An LDAP directory is one common type of user repository with a specific access protocol, but a user repository can be implemented in other ways depending on the deployment. LDAP describes an interface and directory model, not the concept as a whole.

Best practices

Keep the repository's role clear as a store of identity data, and delegate authentication verification and authorization decisions to their respective components rather than embedding those functions in the repository.

Store credential material securely, for example using appropriately hashed passwords, and prefer delegating credential verification to a dedicated authenticator where the deployment supports it.

Automate lifecycle operations such as provisioning and deprovisioning, typically via SCIM, so that lifecycle state stays synchronized with authoritative sources and disabled accounts are reflected promptly.

Maintain accurate attributes, group, and role assignments so downstream RBAC or ABAC decisions operate on current data, while remembering the repository supplies inputs and does not make the decisions.

Include the repository in periodic IGA access reviews and certifications to detect stale accounts, orphaned entries, and excessive privileges.

Restrict and audit read/write access to the repository interface (for example LDAP or SCIM endpoints), since it holds sensitive identity and credential data.