Category: Directory Services

Identity Store

Also known as: Identity Repository, User Store

Simply put

An identity store is a repository that holds information about the users and groups an organization manages, such as their attributes, credentials, and permissions. IAM systems rely on it as a central place to look up who someone is and what is known about them. Think of it as the authoritative record of identities that other identity and access management components read from.

Formal definition

An identity store is a repository that persists digital identities, typically users and groups, along with their attributes, authentication-related data, and, in some deployments, associated permissions or role assignments. It serves as the data layer that IAM components query to identify and retrieve principals; depending on the deployment, it may be implemented as an LDAP directory, a database, or a vendor-specific service (for example, the Identity Store used by AWS IAM Identity Center provides a single place to retrieve users and groups). Note that an identity store is primarily a source of identity data and should not be conflated with the authentication process itself (verifying a principal's identity) or with runtime authorization enforcement; while it may hold credential material and permission attributes, the way that data is consumed for authentication or authorization depends on the surrounding IAM architecture. Whether it functions as an authoritative source of record or a downstream copy varies by configuration.

Why it matters

The identity store is the data foundation that most IAM operations depend on. When an IAM system needs to identify a principal, retrieve attributes, or look up group memberships, it queries an identity store to do so. Because so many downstream functions, identification during an access flow, attribute lookups that feed authentication and authorization decisions, and provisioning targets, read from this repository, the accuracy and integrity of the data it holds directly shape how reliably the surrounding IAM architecture behaves.

The distinction between an authoritative source of record and a downstream copy matters in practice. In many deployments an identity store is a synchronized replica rather than the system of record, and treating a stale or secondary copy as authoritative can lead to access decisions based on outdated attributes or group memberships. Because the identity store may hold credential material and permission attributes, it is also a sensitive asset: how that data is protected and how consuming components use it depends on the surrounding design rather than on the store itself.

It is important not to overstate what an identity store does. It is primarily a source of identity data and should not be conflated with the authentication process (verifying a principal's identity) or with runtime authorization enforcement. Even when it contains credentials or role assignments, the way that data is consumed for authentication or authorization depends on the broader IAM architecture, so the identity store is one component among several rather than the mechanism that grants or denies access.

Who it's relevant to

IAM Engineers

Engineers integrating identity systems must know which identity store a given component queries and whether that store is the authoritative source of record or a synchronized copy. This affects how identification, attribute retrieval, and group lookups behave across the architecture, and whether the underlying implementation is an LDAP directory, a database, or a vendor service such as the AWS IAM Identity Center Identity Store.

Security Architects

Architects designing IAM systems need to treat the identity store as a sensitive data layer that may hold credentials and permission attributes, while keeping it distinct from authentication and runtime authorization enforcement. Deciding where the authoritative record lives and how downstream copies stay consistent is a core design concern.

Identity Governance Leads

Governance leads rely on identity store data, user attributes, group memberships, and any role assignments it holds, as inputs to provisioning and access reviews. The accuracy of that data, and clarity about whether the store is authoritative or a downstream replica, directly affects the reliability of governance processes.

System Administrators

Administrators managing users and groups work directly against identity stores to maintain attributes and memberships. Understanding whether changes propagate from an authoritative source or must be reconciled across copies helps them avoid acting on stale identity data.

Inside Identity Store

Identity records

Persistent representations of principals (users, service accounts, devices) that typically include a unique identifier plus associated attributes. These records are the authoritative or reference data used during identification, prior to authentication.

Attributes

Descriptive fields such as display name, email, department, group memberships, and entitlements. Depending on the deployment, these attributes may feed authorization decisions (for example in ABAC) but the store itself is not the policy decision point.

Credential material

In many deployments the identity store also holds or references credential verifiers such as password hashes, or pointers to external authenticators. Note that storing a credential verifier is distinct from performing authentication, which is a separate step.

Backing technology

An identity store is commonly implemented over an LDAP directory, a relational or NoSQL database, or a cloud directory service. The underlying technology affects schema, query, and provisioning behavior but not the conceptual role of the store.

Provisioning interfaces

Mechanisms by which records are created, updated, and deactivated, often via SCIM or vendor-specific APIs. These are lifecycle (IGA) touchpoints and are typically separate from runtime authentication and authorization flows.

Unique identifiers

Stable keys (for example a directory DN, a UUID, or a subject identifier) used to correlate a record across systems. These identifiers are what identification resolves to before authentication verifies the principal.

Common questions

Answers to the questions practitioners most commonly ask about Identity Store.

Is an identity store the same as an authentication service?

No. An identity store is a repository that holds identity records and their associated attributes and, in many deployments, credential material. Authentication is the process of verifying that a principal is who it claims to be. The identity store typically supplies the data an authentication service consults (for example a stored password hash or an enrolled credential reference), but the store itself does not perform the verification step. Keeping identification (locating the record), authentication (verifying the principal), and authorization (deciding what the principal may do) as distinct steps helps avoid conflating the repository with the services that use it.

Does the identity store also handle authorization decisions?

Not inherently. An identity store primarily provides identity and attribute data. In a runtime access flow, that data may be consumed by a policy information point (PIP) and evaluated by a policy decision point (PDP), with enforcement at a policy enforcement point (PEP). The store can serve as an attribute source that feeds these components, but the authorization decision itself is made elsewhere. Some directories also hold group or role assignments used in RBAC, which influences authorization, yet holding that data is not the same as evaluating and enforcing a policy.

What types of backends are commonly used to implement an identity store?

Implementations vary by deployment. Common options include LDAP-based directories, relational or other database-backed stores, and cloud-hosted directory services. The choice typically depends on factors such as existing infrastructure, schema and attribute requirements, scale, and the protocols consumers expect. Some environments use more than one store and layer a virtual directory or identity synchronization to present a consolidated view.

How is data typically kept consistent across an identity store and downstream applications?

Provisioning and synchronization mechanisms are commonly used. SCIM is one standard often deployed for provisioning and deprovisioning identity records to applications, while directory replication or synchronization jobs may keep multiple stores aligned. The specific approach depends on the systems involved and whether updates flow from an authoritative source outward. Reconciliation processes are frequently used to detect and correct drift between the store and target systems.

How should credential material in an identity store be protected?

Depending on configuration, credential material such as password hashes or references to enrolled authenticators may reside in the store, and handling varies by vendor and standard. Common practices include storing password material as salted hashes rather than reversible forms, restricting read access to credential attributes, and encrypting data at rest and in transit. Note that signing and encryption are different protections: ensuring integrity is not the same as ensuring confidentiality. Specific capabilities and defaults differ across implementations, so verify what a given product provides.

How does the identity store relate to identity governance activities like access reviews?

The identity store is typically an authoritative or contributing source of the identity and entitlement data that IGA processes act upon. Governance activities such as provisioning, access certification, and segregation-of-duties analysis read from and may update records in the store, but these lifecycle functions are distinct from the runtime consumption of store data during authentication and authorization. Treating the store as a data repository, separate from the governance workflows that manage its contents, helps keep lifecycle management and real-time enforcement concerns clearly delineated.

Common misconceptions

An identity store authenticates users.

An identity store holds identity records and, in some deployments, credential verifiers, but authentication is a distinct step performed by an authentication service or authenticator that verifies a presented credential against stored material. Storing a verifier is not the same as verifying a principal.

The identity store decides what a principal is allowed to do.

The store may supply attributes and group or role data consumed by authorization logic, but authorization decisions are typically made by a policy decision point (PDP) and enforced by a policy enforcement point (PEP). The store more often acts as a policy information point (PIP) source rather than the decision authority.

An identity store is always an LDAP directory.

LDAP directories are one common implementation, but identity stores are also built on relational or NoSQL databases and cloud directory services. The choice depends on schema, scale, and integration needs, and no single backing technology is universally correct.

Best practices

Keep the identity store's role as a system of record separate from runtime enforcement: source attributes from it for authorization decisions, but locate decision and enforcement logic in the PDP and PEP rather than in the store itself.

Manage the identity lifecycle (creation, update, deactivation) through governed provisioning interfaces such as SCIM or vendor APIs, and reconcile records regularly so stale or orphaned entries are removed.

Protect stored credential material appropriately, using hashed verifiers rather than recoverable secrets where possible, and treat credential storage as distinct from the authentication process that consumes it.

Define a single authoritative source per attribute to avoid conflicting values across multiple stores, and document which system owns each attribute in federated or synchronized environments.

Use stable, unique identifiers for correlation across systems and avoid reusing identifiers of deactivated principals, since reuse can break audit trails and access mappings.

Validate that schema and integration behavior match your chosen backing technology (LDAP, relational, NoSQL, or cloud directory), and test provisioning and query paths against the specific deployment rather than assuming uniform behavior.