No API? No Problem: Integrating Disconnected Target Systems in SailPoint ISC Using a Logical Architecture

Identity Security Cloud (ISC) ISC Community Knowledge Base
, , ,
1

Problem

  1. Integration Roadblocks: Identity teams frequently hit a wall when attempting direct integration between SailPoint Identity Security Cloud (ISC) and critical target applications.
  2. No Native Connectors: Out-of-the-box connectors for SailPoint ISC are completely unavailable for the specific system.
  3. Missing API Architecture: The target application lacks modern APIs or programmatic interfaces to manage users.
  4. Database Isolation: Direct database connections are strictly blocked due to tight organization-wide security policies or application owner preferences.
  5. Mandatory Compliance: Despite these connectivity hurdles, the business still requires automated Joiner, Mover, and Leaver (JML) lifecycles alongside robust access review processes within the IGA platform.

Diagnosis

  1. The Logical Alternative: When direct integration pathways are blocked, the strategy to bypass these limitations is deploying a Logical Application integration model.
  2. Shifted Governance Boundary: Instead of forcing a direct connection to the target system, the architecture shifts the governance boundary to a controlled, intermediate directory layer—such as Microsoft Active Directory (AD) or Microsoft Entra ID.
  3. Entitlement Mirroring: You establish dedicated Security Groups within the intermediate directory that directly mirror the specific access levels of the disconnected target application.
  4. Targeted Data Aggregation: SailPoint ISC bridges the gap by aggregating the user accounts and corresponding entitlements provisioned to those specific groups.
  5. Identity Correlation: Because a logical architecture introduces identity footprint data across multiple authoritative sources, SailPoint ISC relies on Identity Profiles to determine source precedence. This ensures core identity attributes remain accurate, single-sourced, and perfectly correlated.

Solution

  1. Select Your Directory Foundation: Evaluate and decide which directory solution your organization uses (e.g., Microsoft AD, Entra ID, or OpenLDAP) to serve as your logical application anchor.
  2. Configure the ISC Source: Create a new Source in SailPoint ISC using the native connector corresponding to your chosen directory solution.
  3. Apply Scoping Filters: Configure precise connectivity details and aggregation filters to isolate and pull only the specific accounts and entitlements that belong to the target application, successfully preventing directory bloat.
  4. Trace the Architecture Flow: Provisioning actions deploy directly from SailPoint ISC to the directory layer, where account creation and entitlement assignment take place. Downstream authorization happens within the directory, ensuring that when a user logs into the target system, they see the exact landing page corresponding to their authorized permissions.

Flow Diagram
Flow Diagram1477Ă—430 63.2 KB

Conclusion

Deploying a logical application architecture ensures that technical barriers like missing APIs or native connectors do not leave critical target systems outside your governance scope. By routing provisioning through an intermediate directory layer and leveraging Identity Profiles to manage source precedence, you can seamlessly automate lifecycles and maintain compliance for disconnected applications.

1 Like
2

Been using this as the preferred mode of integration for as long as I can remember. Keeping access controlled via an intermediary directory not only reduces the need to onboard every application separately onto ISC, but also promotes Zero Trust. Good read!