Skip to main content
Identity Authority
Category: Directory Services

Schema

Simply put

A schema is a structured framework or blueprint that defines how information is organized. In the context of data systems, it specifies what kinds of information can be stored and how those pieces relate to one another.

Formal definition

A schema is a formal definition of the organization and structure of data within a system, such as a relational database or a directory service. In a relational database, a schema defines how data is organized, including tables, fields, data types, and their relationships. Note that the specific elements and constraints expressed by a schema vary by system and context; the evidence provided here addresses schema as a general structuring concept and does not detail IAM-specific directory schema mechanics such as LDAP object classes or attribute syntaxes.

Why it matters

A schema establishes the shared structure that lets systems store, validate, and exchange data consistently. In identity and access management, the underlying data, whether it lives in a relational database backing an IGA platform or in a directory service that authentication and authorization decisions depend on, is only as reliable as the schema that organizes it. When the structure that defines what attributes exist and how they relate is well understood, provisioning, access reviews, and policy evaluation can operate on predictable, well-typed data.

Ambiguity or drift in the underlying data structure tends to surface as operational and governance problems. If two systems disagree about how a piece of information is organized or represented, provisioning flows can fail, attribute-based policy decisions can misfire, and reconciliation between authoritative sources becomes error-prone. Because the schema is the contract that all consuming components implicitly rely on, changes to it ripple across every system that reads or writes the data.

It is worth being precise about scope: the evidence here treats schema as a general structuring concept, as reflected in database and web-structured-data usage. IAM-specific mechanics, such as LDAP object classes, attribute syntaxes, and directory-specific constraints, follow the same principle of formally defining structure but introduce additional details not addressed by this general definition.

Who it's relevant to

IAM Engineers
Engineers who integrate identity data across systems depend on a clear schema to know what fields exist, their data types, and how records relate. This structure informs how they map and move attributes between an authoritative source and consuming systems.
Identity Governance Leads
Governance functions such as provisioning and access reviews operate on data whose organization is defined by a schema. A consistent, well-understood structure supports reliable reconciliation and reduces the risk of errors introduced by structural ambiguity.
System Administrators
Administrators who manage directory services and databases work directly with the schema that defines how stored data is organized. Understanding the blueprint helps them anticipate how structural changes propagate to the systems that read and write that data.
Security Architects
Architects designing identity systems treat the schema as the underlying contract that consuming components rely on. Because the data model shapes what information is available for downstream use, defining it deliberately is a foundational design concern.

Inside Schema

Attributes
The named data elements defined by the schema (for example, mail, givenName, or a custom attribute), each with a specified syntax and matching rules that govern how values are stored and compared. In LDAP directories these are formalized as attribute type definitions.
Object Classes
Structural definitions that group related attributes and declare which are mandatory (MUST) versus optional (MAY) for an entry. In an LDAP directory, an entry's object classes determine the set of permitted and required attributes.
Syntaxes and Matching Rules
Specifications that constrain the format of attribute values (such as string, integer, or DN) and define how comparisons and searches are performed (for example, case-insensitive equality matching), depending on the directory or system implementation.
Object Identifiers (OIDs) or Unique Names
Unique identifiers assigned to attribute types and object classes so definitions can be referenced unambiguously, typically as OIDs in LDAP schema definitions, though naming conventions vary by system.
Provisioning Mapping Elements
In a provisioning context such as SCIM, the schema defines resource types (for example User and Group) and their attribute structure, which IGA processes use to map and synchronize identity data between systems.

Common questions

Answers to the questions practitioners most commonly ask about Schema.

Is a directory schema the same thing as a JWT or token claim schema?
No. These operate in different layers and should not be conflated. A directory schema (for example, an LDAP schema) defines the object classes, attributes, syntaxes, and matching rules that govern how identity data is stored and structured in a directory. A token claim structure, by contrast, defines the set of claims conveyed at runtime in a token such as a JWT. While attributes sourced from a directory may ultimately populate claims in a token, the schema that governs the directory is distinct from the claim set carried in a token, and the two are typically managed and versioned separately.
Does the SCIM schema define runtime access enforcement or authorization rules?
No. A SCIM schema is a provisioning and lifecycle-management concern within identity governance and administration, not a runtime enforcement mechanism. It describes the structure of resources such as users and groups so they can be created, updated, and deprovisioned across systems. It does not, on its own, determine what a principal may do at access time; that authorization decision is made by enforcement components such as a PDP evaluating policy. Keeping the provisioning schema separate from runtime authorization logic avoids blurring lifecycle management with real-time access decisions.
How should schema changes be managed to avoid breaking existing identity data?
In most deployments, schema changes are handled through additive, backward-compatible extensions rather than modifying or removing existing definitions, since removing or redefining an attribute can invalidate stored data or dependent integrations. Many teams introduce new attributes or object classes, migrate consuming systems, and only later retire deprecated elements. The exact constraints depend on the directory or provisioning system and the profile in use, so validating changes in a non-production environment before rollout is a common precaution.
How do you extend a schema to support custom attributes without conflicting with standard definitions?
Custom attributes are typically added in a way that avoids collisions with standard or reserved definitions. In LDAP directories, this usually means using registered or uniquely assigned object identifiers and namespacing custom object classes and attributes. In SCIM, custom attributes are commonly placed under a distinct extension namespace rather than overloading core attributes. The precise mechanism depends on the system and standard profile, and confirming naming and identifier conventions against the applicable specification helps prevent interoperability problems.
What should you consider when mapping schema attributes across federated or provisioned systems?
Attribute mapping should account for differences in naming, data types, cardinality, and required versus optional fields between the source and target schemas. Depending on configuration, mismatches such as differing multi-valued handling or format expectations can cause provisioning failures or incomplete data. Where an attribute in one system has no direct equivalent in another, teams typically define transformation or default-value rules. It is also important to distinguish which attributes drive provisioning versus which may later populate token claims at runtime, as these serve different purposes.
How is schema versioning typically handled across integrated identity systems?
Versioning approaches vary by vendor and standard profile, so behavior should be confirmed for the specific systems involved. In many deployments, schema versions are tracked so that consuming systems can detect and adapt to changes, and backward-compatible evolution is preferred to reduce disruption. Coordinating version changes across federated or provisioned integrations generally requires communicating changes to dependent parties in advance, since one system adopting a new schema element before others support it can create inconsistencies.

Common misconceptions

A schema controls what a user is allowed to do or access.
A schema defines the structure and constraints of identity data, not authorization decisions. What a principal may do is determined by access control models (such as RBAC, ABAC, or PBAC) and enforced at runtime by policy components, which are separate from schema definitions.
LDAP directory schema and SCIM provisioning schema are the same thing and interchangeable.
They serve different contexts. An LDAP schema (with object classes, attribute types, and typically OIDs) governs directory entry structure, while a SCIM schema describes JSON resource representations used for provisioning. They may model overlapping identity attributes but use different formats and rules, and mapping between them depends on configuration.
A schema and a token's claim set are the same concept.
A schema defines the structure of stored identity data in a directory or provisioning system, whereas token claims (for example in a JWT ID token or access token) are asserted attributes conveyed at runtime. Claims may be derived from schema-defined attributes, but the token structure and validation are distinct from the underlying data schema.

Best practices

Extend the schema using standard extension mechanisms (such as auxiliary object classes in LDAP or extension schemas in SCIM) rather than modifying core definitions, so upgrades and interoperability are preserved.
Assign globally unique identifiers to any custom attribute types and object classes (for example registered OIDs in LDAP) to avoid collisions across systems and future definitions.
Choose syntaxes and matching rules deliberately for each attribute, since they affect how values are validated, searched, and compared; document these choices for downstream integrations.
Maintain an explicit attribute mapping between directory schema and provisioning schema (for example LDAP to SCIM) as part of IGA processes, and validate it whenever either side changes.
Version and change-manage schema modifications, testing them in a non-production environment first, because schema changes can affect existing entries, provisioning jobs, and dependent applications.
Keep schema design focused on data structure and separate from authorization logic, deferring access decisions to the appropriate access control model and runtime enforcement components.
Promotional banner for the Penetration Report Template Kit