SailPoint IIQ Integration – Read via JDBC queries and Provisioning via REST APIs

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Hi Sailors,

We are currently integrating an application with SailPoint IdentityIQ and wanted to get suggestions on the best approach.

Our application team has provided the following:

* **Database queries (JDBC)** for account and entitlement aggregation.

* These queries are **read-only**.

* We do not have insert/update/delete privileges on the database.

* **REST APIs** for provisioning operations such as:

* Create user

* Update user

* Enable/Disable user

* Add/Remove access

We would like to understand the recommended way to implement this in SailPoint IIQ.

Our questions:

1. Is it a good approach to use a **JDBC Application** only for aggregation (accounts + groups)?

2. For provisioning, since updates can only happen through APIs, what is the best way:

* Use a **Web Services connector** separately?

* Or keep JDBC application and invoke APIs through **Provisioning Rules / Before-After Operation Rules / Custom connector**?

3. How can account correlation and provisioning be handled cleanly when aggregation comes from JDBC but provisioning happens through APIs?

4. Has anyone implemented a similar hybrid integration? Any best practices or things to avoid?

Thanks in advance for your suggestions.

2

As you are rightly assuming, using two separate applications would complicate things. There will be duplicate accounts in IIQ for each target account.

IMO, if the API are not that complex then JDBC connector would be better choice for aggregation and provisioning rules to call API.

Custom connector make sense if the API are complex and need special handling and you want to keep IIQ side of onboarding clean and move the complexity to custom connector

3

Hi @Harikrishna_06 ,

The recommended approach would be to use JDBC connector and use APIs to perform Create , Update and Delete Operations in Operation specific rules in JDBC

4

Thank you for the replies. Is there any other better approach recommended.

5

@Harikrishna_06 Please check this post: https://community.sailpoint.com/t5/IdentityIQ-Forum/Mixed-connector-for-in-outbound/m-p/131985#M113866

So you might want to configure two apps: one for aggregation and webservice one for provisioning. This type of integration called as Dual Channel or Mixed Connector.

6

Hi @Harikrishna_06 ,

You can make use of integration config to handle this requirement.

Solved: Integration Config vs Before Provisining Rule - Compass

Solved: Integration Config Architecture Question - Compass

Thanks

7

Hi,
Please find my response:

Use a single JDBC Application for everything — aggregation and provisioning both managed under one application. Avoid creating a separate Web Services connector.

  1. Aggregation via JDBC
  • Use JDBC connector purely for account and group/entitlement aggregation
  • Configure separate SQL queries for account aggregation and group aggregation
  • Since access is read-only, JDBC is perfectly suited and no workarounds needed
  • Enable delta aggregation if your queries support filtering by last modified date to avoid full table scans every time
  1. Provisioning via REST APIs
  • Attach a ProvisioningRule directly to the JDBC application
  • This rule intercepts all provisioning operations and routes them to your REST APIs
  • Handles all operations — Create, Modify, Enable, Disable, Delete, Add/Remove access
  • No need for a separate Web Services connector
8

Hi @Harikrishna_06
What I have done in such cases previously is:

  1. Use JDBC connector to perform account/group aggregation

  2. Build an IntegrationConfig and custom Integration executor class to invoke rest apis to do the provisioning.

  3. Register your application in integration config to use integration executor for the provisioning.

    Let me know if you have any further questions

9

Hi @pradeep1602 ,

Can you please share the reference for integrationconfig and java code.

It will be helpful to work.

Thank you

Harikrishna

10

Hi @Harikrishna_06 ,

Unfortunately I don’t have access to the code I built previously.
But I am sure if you search on community.sailpoint.com you can find some examples.

11

You can probably refer this post as well:

Please mark this as solution if it resolves your query

12

You can also use this as reference:

Note: this has created a multiple custom class design you might need to follow the same. Just review and let me know if any additional questions

13

Hi @pradeep1602 ,

Thanks for the suggestion.

I will try and test it.

Thank you

Harikrishna

14

Things to Consider

1. Correlation Between JDBC and API

The account identifier returned by aggregation must match the identifier used by the API. Aggregation and provisioning are independent operations in SailPoint. A common design is to use JDBC for aggregation because database reads are efficient, while provisioning is performed through application APIs to ensure business rules, auditing, and validations are executed. This hybrid approach is widely used when the target application stores data in a database but exposes supported APIs for account management.

15

I had a similar scenario before, where we used the out-of-the-box (OOTB) connector for aggregation and APIs for provisioning. This link should be helpful for your use case.

I also have a question: what is preventing you from using APIs for both aggregation and provisioning?