Approach of Integrating an application using WebService Based Connector

Problem

After discovery sessions with application owners to integrate their application in Identity Security Cloud (ISC), deciding to use a Web Service based connector and directly jumping into the configuration adds significant complexity, which eventually leads to a higher ETA.

Diagnosis

The main issue is the lack of a structured approach. A defined methodology must be in place before diving into configurations for source integration in SailPoint ISC.

Solution

  1. Gather web service details, authentication methods, and setup service accounts from the Application Owners.
  2. Study API documentation and accurately map the endpoints for common operations such as Create/Modify/Disable Account, Add/Remove Entitlement, Aggregation tasks, and Test Connections.
  3. Set up a POSTMAN client to test these APIs; once testing is successful for approximately 70% of the in-scope operations, you can begin the source configuration in SailPoint ISC.
  4. Follow a strict 10-step chronology during setup, starting with Test Connections and ending with Remove Entitlement, to ensure a constructive integration approach. The operations which we mostly implement in ISC while integrating an application is as follows. (Follow the below chronology)
  • Test Connections
  • Aggregate Accounts
  • Aggregate Entitlements
  • Single Account aggregation
  • Create Account & Add Entitlement
  • Modify Account
  • Disable Account
  • Enable Account
  • Delete Account
  • Remove Entitlement

Hello Rohit. Thank you for sharing this article. It provides a useful starting point for planning a Web Services source integration.

A few points I would like to suggest:

  1. It may be helpful to use the official operation names, such as Test Connection, Account Aggregation, Group Aggregation, Get Object, Create Account, Update Account, Add Entitlement, and Remove Entitlement. This would make it easier for readers to map the guidance to the operations available in the connector.

  2. Listing Create Account and Add Entitlement together may imply that they are always processed as a single operation. They are separate operations by default. Entitlement attributes can be included in the Create Account operation only when Create Account With “Ent” Request is enabled and the target API supports that request structure.

  3. The 10-step chronology and 70% Postman testing threshold appear to be project-specific recommendations rather than SailPoint requirements. It may be better to present them as suggested guidance, since the required operations and implementation order depend on the target API and the use cases in scope.

Since this is a Knowledge Base article, elaborating on the article as a whole and adding more implementation context could make it even more useful for readers.

2 Likes