Scaling Identity Governance Without Connectors: The LDAP Directory IGA Integration Pattern

In Identity Governance and Administration (IGA), connectors help keep user accounts, roles, and access permissions in sync across your applications.  

What if you don’t deploy a connector? What about legacy and cloud applications that don’t support SCIM, or systems handled by third-party vendors that don’t allow inbound connections?

Governance black holes often result from a breakdown in the traditional model connector. What is the solution? Flip the model over.

This article delves into the LDAP Directory-Driven Connector Pattern, a robust yet often overlooked methodology for scaling identity governance across the most complex parts of your application environment.

The Problem: The "Unconnectable" Application

Now let's set the scene. IGA is your responsibility, and you need to manage access to it:

• A legacy mainframe application that only knows how to communicate with an LDAP directory.
• A critical SaaS platform where the vendor manages user provisioning directly in their own LDAP store, and they won't give you API access.
• Home-grown application that authenticates and authorizes users against a read-only copy of the corporate Active Directory.

There is no possibility of creating a traditional agent-based or API-driven connector in each of these cases. IGA cannot "push" or "pull" data directly from the source. The result is a massive risk: unmanaged, ungoverned, and un-auditable access.

The Solution: Treat the Directory as the Source of Truth

The approach, instead of connecting directly to the application, is to connect to the LDAP directory that is already used by the application for authorization.

In other words, the LDAP directory is the connector.

This pattern does not store user roles in the disconnected application's own local database. Instead, it reads a user's group memberships or specific attributes from a central or application-specific LDAP directory. Based on membership in a directory group, access decisions are made.

This IGA system, which can connect to this LDAP directory, now includes a channel for governance. The application manages access by managing group membership in the directory, which the application then consumes.

Architectural Flow

Here's how the data flows in this pattern:

1. Provisioning: It is approved in the IGA system for User A to have the Finance-Approver role in App-X.
2. Translation: In the IGA system, the Finance-Approver role is translated into an LDAP group membership. LDAP knows that membership in the cn=appx_finance_approvers,ou=appx,ou=groups,dc=company,dc=com possesses that role.
3. Execution: By connecting to the target LDAP directory (e.g., Active Directory, OpenLDAP), the IGA system adds User A's Distinguished Name (DN) to the list of group members.
4. Consumption: The disconnected App-X periodically authenticates/authorizes User A against the same LDAP directory. As a result, it reads the group memberships of the user, sees the appx finance approvers, and grants access accordingly.
5. De-provisioning: In the IGA system, access is revoked when a user is removed from the LDAP group, which results in App-X blocking access during the next authorization cycle.

This creates a clean, loosely coupled architecture in which the IGA system governs access without it being necessary to understand the internal logic of the application.

Diagram: A flowchart showing how the IGA system manages group membership in an LDAP Directory, which is accessed by a disconnected application.

Implementing the Pattern: A Practical Example

Let's walk through how a legacy application is implemented at a high level, CRMBridge.

Assumptions:

• CRMBridge OpenLDAP server is configured for authorization.
• Access to CRMBridge is governed by membership in LDAP groups, such as crm_admin, crm_reader, and crm_editor.

Step 1: Schema and Directory Modeling in IGA

As a first step, we model the LDAP directory itself as a "connected system" in the IGA platform. We create an LDAP connector that points to our OpenLDAP server.

The next step is to model the CRMBridge application. The IGA system automatically detects LDAP groups instead of its "native" roles.

• IGA Role: CRMBridge - Administrator -> LDAP Group: crm_admin
• IGA Role: CRMBridge - Editor -> LDAP Group: crm_editor

Step 2: Reconciliation (The "Pull")

In the IGA system, the LDAP directory is reconciled (or imported) at regular intervals. Reads members of groups crm_admin, crm_editor, etc. By doing that, the IGA system's identity warehouse is populated with the current access status: "Who has what access in CRMBridge?"

It is essential for attestation and analytics. It is now possible to run certification campaigns on CRMBridge access, even if you have never used CRMBridge.

Step 3: Provisioning (The "Push")

As soon as a user is granted a CRMBridge - Editor role, the provisioning workflow executes a single task: Add user to LDAP Group.

Using the LDAP connector, the IGA system modifies the crm_editor group to include the user's DN.

Step 4: De-Provisioning

An LDAP modification operation is also triggered by revocation in order to remove a user from a group.

Benefits and Advantages

• Governance for "unconnectable" apps: Primary benefit is bringing critical but disconnected applications under identity governance.
• Simplified architecture: Reduces the need to build complex, custom connectors. LDAP is a standardized protocol that is well understood.
• Loose coupling: IGA workflows are unaffected by changes to the application (as long as its LDAP integration remains stable).
• Centralized audit trail: Access changes are logged and managed from a single platform (the IGA), which provides a clear audit trail.

Challenges and Considerations

• Limited attribute scope: Only the directory's data (groups, attributes) can be managed. Unless the settings are directory-driven, you cannot manage application-specific settings.
• Orphaned accounts: Users provisioned directly in the application's local database can fall outside of this governance model. A strict policy requiring all access to be directory-based is essential. Organizations often use hybrid approaches to identify and resolve account issues relating to applications that do not exist in the governed directory structure using periodic directory-versus-application account reconciliations.
• Directory schema handling: You need to manage the LDAP group structure cautiously to prevent clusters and confusion. As the system grows, it becomes difficult to keep track of the growing number of groups, necessitating clear naming rules, organized hierarchical units, and lifecycle management processes.
• Reconciliation lag: The IGA system can only see the access information from the latest and most recent LDAP sync. If you require real-time attestation, you will have to perform imports more often. There will always be a delay, a small one may be when someone accesses the changes in the directory, and when the application actually reflects that change. The important factor is to find the right balance between how often you sync and how much delay your compliance and security polices can allow.

Conclusion

When you cannot deploy a traditional connector for your identity governance efforts, it’s not the end of the road. By employing LDAP Directory-Driven implementations, you can extend the IGA system to cover even hard-to-integrate and isolated applications.

During such setup, the IGA system is connected directly to the application's source of truth rather than depending on the application to connect back. It is an effective solution that offers to close governance gaps, minimize the number of separate connectors, and create a more robust and powerful identity environment.

Did you implement a similar pattern? In what ways did you face challenges? Feel free to share your thoughts in the comments section!