Configure single webservice connector with multiple tenants

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

We have requirement to enable provisioning, aggregation for an app with 36 tenants which has accounts and roles respectively,there is no sync across tenants.to avoid redundant source creation plan is to configure single source to pull accounts and roles from all the tenants. The account and role should have an indicator saying t was pulled from specific tenant.

Please suggest best possible solution.

Tried creating different entitlement types and in aggregation operations header passed the url,auth param but it is taking only the base configuration param.

2

Hi @pnandhakumar

I don’t think there is any out of the box way of integrating this, but it’s definitely possible using the before and after operation rules on the web service connector.

I think the easiest solution would be an individual source for each tenant, but if that’s not an option, you could pivot to using before & after operations rules. Going the rules route would likely need an account aggregation and group aggregation operation for each tenant. You could also do all the logic in one before and after operations rule, but that will start to get messy quick. To differentiate the tenants, you would just need to append the tenant name in a after operation rules for the account & group names.

1 Like
3

Have you considered custom connector?

4

No Nitesh, new to IDN and with limited timeline we will try with before and after op rules..

5

we will try and get back for further guidance

6

can you please share an example, tried beforerule to update the credentials in requestEndPoint using add header but it is taking only the base configuration. In our requirement al tenants will have same API /url but only user name , password differs.. Same is working fine in postman

7

I don’t have an example for you, but at a high level I think the flow will look like this:

  1. Create Account Aggregation / Group Aggregation Operation For Each Tenant
  2. Put the username for that tenant in the headers for that operation.
  3. Create an “encrypted” variable for the password for each tenant in the JSON source configuration, you could name it something like this: “tenant_password”. Assign the password to that value in the JSON source configuration.
  4. Reference that encrypted variable in the headers of the operation ($application.tenant_password$).
  5. Perform authentication in before operation rule with the passed in username / password that we set in the header using getHeader().
  6. Replace the header with the authorization token that you got from authentication and set that using setHeader().
  7. In the after operation rule, modify the data to concatenate the tenant name in the id/name field - “tenant-accountname” & “tenant-groupname”

Let me know if you have any other questions/concerns!

1 Like
8

thanks for taking time in explaining the process in detail Tyler, the connector uses basic auth type and we have to jus pass username and password. created aggregation object and tried to pass username and credentials from header it didn’t work always taking base config values. Attached screen shots for reference.. (Note - username and password is dummy since am sharing replaced it)

image
image1285Ă—637 21.1 KB

image
image1282Ă—610 22 KB

9

Since you are no longer using the base config for authentication, you will need to update that in the before operation rule and perform/prep the authentication yourself.

I haven’t tested this, but I think you should be able to do something like this inside the before operation rule:

Map header = requestEndpoint.getHeader();
String username = "username";
String password = "password";
String authString = username + ":" + password;
String encodedAuth = Base64.getEncoder().encodeToString(authString.getBytes("UTF-8"));
header.put("Authorization", "Basic " + encodedAuth);
requestEndpoint.setHeader(header);
10

“to avoid redundant source”…sounds to me this creates more complexity than necessary. The usual “can you” vs “should you” type of requirement. The sources are not “redundant” if they are unique to each tenant. And you should have tenant-specific credential for each outbound connection… So, who’s providing this, IMO, incorrect “redundant” narrative?

1 Like
11

Agreed. I can think of a few reasons why this will cause complexity and issues later down the line even if this is executed properly.

  1. Aggregation times are going to be significant
  2. Source configuration will be difficult to troubleshoot since there will likely be 50+ operations on the source unless you choose to do all the logic inside a rule (even less visibility)
  3. Storing 36 different password variables on the source will be difficult to manage and wont have credential provider support.

Overall, I think creating one source, configuring it then copy/pasting it across and updating the username/password/url in the UI, would be a far simpler approach. But I like the idea of trying to do it all in one source!

12

I typically take the approach / opinion that if you need to do substantial coding to augment behaviour of a product, you better do that on the product end, not on the consumer / user / tenant side.

It’s like, if I don’t like the taste of my current scoop of ice-cream, I either add additional flavouring (to an extent), or get a different flavour. I don’t go and gene-modify the ice-cream from milk to oat milk. This applies to most services / products / solutions in order to maintain low cost / low complexity / fast to use pace on the consumer end.

i.e. By the time a tech has reached implementors in the pipeline, you taper your development effort, and focus more on configuration, get the product usable, get the benefit, fast turnaround. To a degree, this is even more true for clients / customers who have opted for SaaS, where “manage less” has been consideration, be it less on-prem infrastructure, less OS licensing, less…code / dev-ops. Keep it lean.

2 Likes
13

we are planning to go with separate source for individual tenants, getHeadet and restcliet.executeGet both didnt give expected results. Thank you all for ur suggestions