Category: Directory Services

Cloud Directory

Also known as: Cloud Directory Service

Simply put

A cloud directory is an identity service delivered from the cloud that stores information about users and groups and, in many offerings, centralizes tasks like verifying who a user is and applying access policies. Rather than running directory infrastructure on-premises, organizations consume it as a hosted or SaaS service. The specific capabilities vary considerably from one provider to another.

Formal definition

A cloud directory is a cloud-hosted repository of identity objects, typically users and groups, that in many offerings is delivered as SaaS and may centralize authentication, access policy, and sometimes device management. The term spans a range of products with differing scope: some are general-purpose directory stores designed for large-scale, cloud-native object hierarchies (for example, Amazon Cloud Directory, described as a highly available multi-tenant directory-based store that scales to large numbers of objects), while others function as identity platforms that manage regular and federated users and enforce access policy (for example, IBM Verify Cloud Directory, described as a repository for regular and federated users and groups). Because implementations differ, a given cloud directory may or may not provide authentication, authorization policy enforcement, provisioning, or device management; these capabilities should be confirmed per vendor and configuration rather than assumed. The evidence does not specify supported protocols (such as LDAP, SCIM, SAML, or OIDC) for these offerings, so protocol support is out of scope for this definition.

Why it matters

Directory services are the backbone of identity infrastructure: they hold the authoritative records of who exists in an organization and how those identities are grouped. As organizations shift workloads and applications to the cloud, running and maintaining on-premises directory infrastructure becomes an operational burden, and a cloud-delivered directory lets teams consume that capability as a hosted or SaaS service rather than provisioning and patching servers themselves. This shift can reduce operational overhead and, depending on the offering, provide elasticity that on-premises deployments struggle to match.

The practical significance is complicated by how much the term varies in meaning. Some cloud directories are general-purpose, cloud-native object stores designed for very large hierarchies (Amazon Cloud Directory is described as a highly available multi-tenant directory-based store that scales to hundreds of millions of objects), while others are identity platforms that manage regular and federated users and enforce access policy (IBM Verify Cloud Directory is described as a repository for regular and federated users and groups). Treating these as equivalent can lead to architectural mistakes, because a developer-oriented object store and a full identity platform address different problems.

For security and identity teams, this variability means capabilities cannot be assumed. Whether a given cloud directory verifies who a user is, applies access policy, provisions accounts, or manages devices depends on the specific vendor and configuration. Evaluating a cloud directory therefore requires confirming its actual scope against the organization's requirements rather than relying on the category label alone.

Who it's relevant to

Security architects

Architects choosing between an on-premises directory and a cloud-delivered one need to understand that the term spans very different products, from developer-oriented object stores to full identity platforms. Mapping a specific offering's actual scope, storage only, or storage plus authentication, access policy, and device management, to the organization's requirements is essential before committing to a design.

IAM engineers

Engineers implementing and integrating a cloud directory must confirm which capabilities a given offering provides, since authentication, access policy enforcement, provisioning, and device management may or may not be included depending on vendor and configuration. Because the evidence does not specify protocol support, engineers should validate directory, provisioning, and federation protocol compatibility directly with the vendor rather than assuming it.

Application developers

Developers building cloud-native applications may use a general-purpose cloud directory as a directory-based store capable of scaling to large object hierarchies (as described for Amazon Cloud Directory). This use case is distinct from consuming an identity platform that manages regular and federated users, and developers should select the offering that matches whether they need a scalable object store or user identity management.

System administrators

Administrators responsible for identity infrastructure benefit from consuming directory capabilities as a hosted or SaaS service instead of running and maintaining on-premises directory servers. They should still verify, per vendor and configuration, exactly which functions the service centralizes for their environment.

Inside Cloud Directory

Identity records

Entries representing principals such as users, service accounts, and sometimes devices, each typically holding attributes (for example display name, email, group memberships) that other systems consume for authentication and authorization decisions.

Cloud-hosted store

A directory service operated as a managed, multi-tenant or vendor-hosted platform rather than as an on-premises server, with availability, scaling, and maintenance typically handled by the provider depending on the offering.

Access interfaces and protocols

Mechanisms for reading and managing directory data. Depending on the vendor these may include REST/Graph-style APIs and, in some deployments, LDAP-compatible endpoints; support varies by product and should not be assumed.

Provisioning integration

Interfaces for creating, updating, and deactivating identities, commonly via SCIM in many deployments, connecting the directory to downstream applications as an identity governance and administration (IGA) concern distinct from runtime enforcement.

Groups and organizational structure

Constructs used to organize identities, such as groups or organizational units, which are often referenced by access control models like RBAC but are data structures rather than an access control model themselves.

Authentication support

Facilities that let the directory serve as an identity source for authentication, often integrated with federation and SSO protocols; the directory typically supplies verified identity data rather than defining what a principal may do.

Common questions

Answers to the questions practitioners most commonly ask about Cloud Directory.

Is a cloud directory just an on-premises LDAP directory hosted in the cloud?

Not necessarily. While some cloud directories expose LDAP-compatible interfaces, many are purpose-built identity stores that expose REST APIs, SCIM endpoints, and proprietary query interfaces rather than native LDAP. Treating a cloud directory as merely a lifted-and-shifted LDAP server can lead to incorrect assumptions about schema flexibility, query semantics, and protocol support. Verify the specific interfaces and standards a given cloud directory supports before assuming LDAP parity.

Does a cloud directory handle authentication and authorization for my applications?

A cloud directory is primarily an identity data store for principals and their attributes; it addresses identification by holding identity records. Authentication (verifying who a principal is) and authorization (determining what a principal may do) are typically handled by separate components or services that consult the directory, though some vendor platforms bundle a directory with authentication and policy services. Keep these as distinct steps: the directory holds attributes, an authentication service validates credentials, and an authorization layer evaluates access. Confirm what your specific platform includes rather than assuming the directory itself enforces access.

How does a cloud directory typically integrate with provisioning workflows?

In most deployments, provisioning into and out of a cloud directory is handled through SCIM or vendor-specific APIs, allowing user and group records to be created, updated, and deprovisioned from an authoritative source such as an HR system or IGA platform. The directory serves as a target or source in these flows depending on configuration. Provisioning is an identity governance and administration concern and should be distinguished from runtime access enforcement; confirm which SCIM version or API profile your directory supports and how deprovisioning propagates.

What identity data model or schema should I expect when adopting a cloud directory?

Schema flexibility varies significantly by vendor. Some cloud directories offer extensible, custom attribute schemas, while others constrain you to a predefined set of attributes and object types. Before adoption, map your required principal attributes, group structures, and any custom attributes to what the directory supports, and check whether extensions are permitted. This matters for downstream consumers such as attribute-based access control (ABAC) policies that depend on specific attributes being present and queryable.

How do applications and services typically consume identities from a cloud directory?

Consumption patterns depend on the interfaces the directory exposes and the integration model. Applications may query the directory through REST APIs or LDAP-compatible endpoints, or they may consume identity data indirectly through a federation or authentication service that reads from the directory and issues tokens or assertions. When tokens are involved, the directory's attributes may populate claims, but the directory itself is generally not the token issuer. Confirm the supported consumption interfaces and how directory attributes flow into any tokens or assertions your applications rely on.

What availability and data residency factors should I evaluate for a cloud directory?

Because a cloud directory is a shared identity data store that many authentication and provisioning flows depend on, its availability directly affects those dependent services. Evaluate the vendor's stated availability characteristics, replication and failover behavior, and any regional or data residency options that affect where identity data is stored. These factors vary by vendor and deployment tier, so review the specific service documentation and any applicable compliance requirements rather than assuming a particular guarantee.

Common misconceptions

A cloud directory is just a traditional LDAP directory running in the cloud.

While some cloud directories expose LDAP-compatible interfaces, many are API-first services with different data models, access methods, and operational characteristics. LDAP support varies by vendor and should be verified rather than assumed.

A cloud directory handles authorization and decides what users can access.

A directory primarily provides identification and supports authentication by supplying identity attributes and group data. Authorization decisions are typically made by separate policy components (for example a PDP evaluating RBAC, ABAC, or PBAC rules); the directory is a source of attributes, not the enforcement point.

Storing identities in a cloud directory covers identity lifecycle governance.

Holding identity records is distinct from IGA processes such as provisioning, access reviews, certification, and segregation-of-duties enforcement. A directory is often one component within a broader governance program rather than a substitute for it.

Best practices

Confirm which access interfaces the specific product supports (for example REST/Graph APIs versus LDAP-compatible endpoints) before designing integrations, since support varies by vendor.

Use standards-based provisioning such as SCIM where available to automate joiner-mover-leaver flows, and treat this lifecycle automation as an IGA concern separate from runtime access enforcement.

Keep the directory as an authoritative source of identity attributes and delegate authorization decisions to a dedicated policy layer rather than encoding entitlements solely as directory groups.

Integrate the directory with federation and SSO protocols (such as SAML 2.0 or OpenID Connect) for authentication rather than relying on ad hoc credential handling in each application.

Establish attribute governance so that fields consumed by downstream access control models (RBAC, ABAC) are accurate, consistently populated, and periodically reviewed.

Review the provider's stated availability, data residency, and maintenance responsibilities, and validate against your compliance requirements rather than assuming behavior.