Part 1: The Datastore

Part 0: What Modern Identity Management Solutions Should Look Like?

Part 1: The Datastore

Part 2: Connectors

Part 3: The Sync Engine

Part 4: The Workflow Engine

Part 5: The Customers and What to deploy?

Part 6: Engineering challenges - Connectors

Part 7: Consulting challenges – Why do most RBAC / ABAC Deployments Fail?

Part 8: IAM People Management challenges

Part 9: The Unspoken Realities of Identity Management

Part 10: Confessions of a Former Hacker: From Script Kiddie to Identity Management Advocate

Part 11: What Are the Gaps in Current Identity Management Solutions?

Part 12: How to Deliver IAM Solutions While Keeping Everyone Sane

Part 13: Identity Management in the era of AI and LLMs

Part 14: Future Trends in Identity Management for 2025-2030

Back in the year 2000, the best option available for Identity and Access Management (IAM) was OLTP databases. They served the purpose well, despite their limitations. They were particularly poor at geo-fencing, data sharding, and scalability. Those that managed to perform decently required a team of skilled database administrators to maintain, involving extensive server racks and sophisticated replication setups.

The Evolution to NoSQL

The emergence of NoSQL brought a new language, incompatible with ANSI-SQL. While convenient for storing documents or key-value pairs, NoSQL was not optimal for write operations and complex joins. Much of the business logic had to migrate from SQL stored procedures to worker processes, leading to issues like data inconsistency, lack of guaranteed transaction retries, and potential transaction loss events. These limitations were tolerable for online stores but unacceptable for IAM solutions.

The Rise of Graph Databases

About a decade ago, Graph Databases began to gain traction, with some backed by major technology firms (FAANG). They matured significantly and now offer advantages from both OLTP and NoSQL worlds. Graph Databases can store JSON blobs, update internal references swiftly (like group memberships), and provide some degree of data sharding and replication.

However, Graph Databases face challenges with GDPR compliance, geo-fencing, and private clouds. Many enterprises operate in both government and public clouds, often needing separate instances for different countries. This requirement introduces the need to reference objects in other databases, similar to foreign security principals in Active Directory Domain Services (AD DS) that point to users in other forests.

Graph Databases for IAM

Graph Databases are highly effective for storing not only identities but their holograms as well. These holograms can represent different states of an object, such as escrowed-export, pending-import, synchronized, unapplied-export, and unconfirmed-export holograms. Microsoft Identity Manager (MIM) was pioneering in using such holograms, contributing to its long-lasting presence in the market.

Benefits of Holograms (and delayed operations) in IAM:

• Control Over Data Queues: Holograms provide control over inbound and outbound data queues.
• Aggregated Exports: They enable batching of exports, significantly enhancing performance.
• Simulation and Dry Runs: Holograms allow for previews and simulations of synchronization rules.
• Mass Update Prevention: They help prevent mass updates due to data source failures.
• Error Detection: Holograms help identify failed exports or discrepancies between expected and actual data.
• Efficient Updates: They facilitate updates by comparing 'as-is' and 'as-to-be' states. You can easily build a delta between ‘as-is’ and ‘as-to-be’ states to push updates to those specific properties and not to replace the whole object.
• You see what failed on export, or when your target system is not really accepting changes you made (you export a value of ‘A’ but on a subsequent import you get value ‘B’ and connector raised no errors on export)

Visualizing the Metaverse Schema

A basic metaverse schema with nodes and holograms includes:

• Application: An application instance, e.g., SAP ER2/700.
• Role: A collection of system roles, permissions, and groups.
• Account: A collection of accounts owned by a person, possibly with temporal role assignments.
• Person: An individual with multiple accounts and HR records.
• Employee: An HR record linked to a person.
• Hologram: A set of five holograms per managed connected system object (e.g., an account, an employee).

Other elements, such as role and application holograms, various relationship types, and business roles, are not depicted but are integral to a comprehensive metaverse schema.

Side note: some IAM system are so good in data synchronization and JML workflows, that are often used as a CMDB-store or a ticketing system. Graph DBs do support that natively.

Let’s visualize one Application (SAP ER2), one role (Treasurer), one account (jdoe@), one person (John Doe) and one employee record (Doe, John):

?

Time-Based Assignments

Graph Databases support time-based assignments. For instance, assigning the role of Treasurer to an account with specific start and end dates can be done using queries. This functionality is essential for fetching active authorizations based on the membership's active status.

Sample Graph-QL query:

MERGE (Treasurer)-[:MEMBER {NOT_BEFORE:'2024-01-01', NOT_AFTER:'2024-09-01'}]->(JDoe)

Market Options and Performance

There are numerous commercial Graph Databases available, with varying performance capabilities and support for cross-instance referencing. The choice of a suitable database often depends on performance requirements and the ability to reference objects across different instances.

By integrating Graph Databases and leveraging their capabilities, modern IAM solutions can achieve a new level of efficiency and effectiveness, meeting the stringent demands of today’s enterprises.

Previous: What Modern Identity Management (IdM/IAM/IGA) Solutions Should Look Like?

Next: Part 2: Connectors