SailPoint IIQ Web Services Connector - Best Practice for Multi-Tenant SaaS Application with Same API Endpoint and Different Bearer Tokens

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Hi SailPoint Experts,

I am currently onboarding Cisco Crosswork Network Insights into SailPoint IdentityIQ using the Web Services Connector.

The application has 3 separate tenants:

1. Telstra

2. Belong

3. Digicel

Current observations:

- All 3 tenants use the same API endpoint:

https://crosswork.cisco.com/api/v1/users

- Authentication is performed using Bearer Tokens.

- Each tenant has a different Bearer Token.

- Users are tenant-specific and data returned depends on the token being used.

For example:

Belong Token ā†’ Returns Belong users

Telstra Token ā†’ Returns Telstra users

Digicel Token ā†’ Returns Digicel users

I have already successfully configured and validated for Belong Tenant:

āœ“ Test Connection

āœ“ Account Aggregation

āœ“ Correlation (email ā†’ email)

āœ“ Entitlement Aggregation

āœ“ Managed Entitlement Promotion

āœ“ Create Account (POST)

āœ“ Enable Account (PUT)

āœ“ Disable Account (PUT)

āœ“ Access Modification (PUT)

My question is regarding the onboarding design.

What is the recommended SailPoint IdentityIQ best practice for this scenario?

Option A:

Create 3 separate SailPoint applications:

- Cisco Crosswork - Telstra

- Cisco Crosswork - Belong

- Cisco Crosswork - Digicel

Each application would have:

- Same API endpoint

- Same Schema

- Same Aggregation configuration

- Same Provisioning configuration

- Different Bearer Token

Option B:

Create one SailPoint application and implement token-routing logic using rules to dynamically select the Bearer Token based on the requested tenant.

Has anyone implemented a similar multi-tenant SaaS onboarding pattern using the Web Services Connector?

From a supportability, governance, certification and operational perspective, what approach would you recommend?

Any guidance, implementation examples, or lessons learned would be greatly appreciated.

Thank you.

2

Hi @kazi_1234, I would go with option A, 3 separate applications.

The duplication in the application configurations will be a lot easier to deal with than trying to make option B work.

3

@paul_hilchey Thanks for sharing the approach.
Appreciated!