Enable Account in Web Services connector

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

I’m at my wits end with the ISC Web Services connector and I’m looking for some help. My requirement seems simple enough:

  • An account must be enabled before an entitlement can be assigned to it

However, as far as I can tell this is simply not possible. Here is what I have tried:

  1. Prioritize the HTTP calls so that Enable Account always runs before Add Entitlement
    1. It looks like ISC does not support this
  2. Ensure Add Entitlement is a dependent operation for Enable Account, so that every time Add Entitlement is called, Enable Account runs
    1. I can’t find any documentation or information on how to reliably tie these operations together as dependencies
  3. Implement logic in a before operation rule to call the app and enable the account
    1. The provisioning plan for Add Entitlement does not include the username of the account, which I need to call the enable user endpoint

Additionally, it looks like almost nothing in SailPoint actually triggers the Enable Account operation. The account is disabled and you add a role? Nope. The user does not have the source and you add it? Nope.

How is this supposed to work? It doesn’t seem that odd to have to enable an account before you can add entitlements to it, but unless I’m missing something, there’s no way to implement that here.

2

Hi @jimjohnson

For #1 & #2 you are correct that these are not possible out of the box as far as I know.

For #3 , the account id should be passed in the provisioning plan in the before operation rule. I would suggest calling the enable endpoint from the before operation rule with that native identity id that is passed in.

You can get that id using this line of code:

String userid = provisioningPlan.getNativeIdentity();

3

Hi, @jimjohnson.

Hope you’re doing great!

As mentioned by Tyler, try to use the native identity (the Account ID defined in the application schema) in your enable request.

If native identity is not the right value for your enable call through a before-operation rule, another option is to leverage an ISC trigger (such as “Access Request Submitted” or “Access Request Decision”) and place the enable account operation inside a workflow. This way you can ensure the account is enabled before entitlements are assigned.

Hope it helps.

4

Unfortunately, String userid = provisioningPlan.getNativeIdentity(); retrieves the SailPoint Identity alias, which is akin to a display name, not the actual username for the application we are trying to call.

I think I found a workaround. It looks like the body of the operation can be configured with parameters from the application user schema:

{
“firstName”: “$plan.firstName$”,
“lastName”: “$plan.lastName$”,
“email”: “$plan.nativeIdentity$”
}

and then in beanshell you can extract the body:

Map body = requestEndPoint.getBody();
Map bodyData = JsonUtil.toMap(body.get(“jsonBody”));
String email = bodyData.get(“email”);

but it feels like unnecessary complexity and SailPoint should just provide this information in the provisioning plan natively.

Also, we can re-enable the user directly in the application using this method, but the account object in SailPoint will still reflect the old LCS (disabled) until scheduled aggregation runs. Is there any way to update that to match more quickly?

I still find it odd that SailPoint does not assume the user needs to be enabled when they are reassigned to a role or source and call the “Enable Account” endpoint. That operation seems functionally useless.

5

Ah I see, I was assuming your identity ID and account username were the same.

Completely agree on the lack of info in the provisioning plan OOTB.

The attribute for whether the account is showing as disabled or not in the UI is called iiqdisabled. I believe if you set this value to false in the response mappings, it should set the account to enabled before an account aggregation.

6

HI @jimjohnson these below are possible solution:-

  1. call enable account api from add entitlement configuration.
  2. call the add entitlement api and in before webservice rule u can call the enable end point first and then normal call can process
  3. to run single account aggregation u can call the get object api(single user api) from after whatever call u want to proceed.
7

Hi @jimjohnson,

If the account details are not available in the provisioning plan, how will the Add Entitlement API work ?

If the details are available, you can use the same information to first enable the account and then add the required entitlement.

8

As far as I can tell, the provisioning plan available in the before operation rule for Add Entitlement only contains the role name being added. No user information. This is separate from the provisioning plan which is available in the HTTP Operation configuration.

@trettkowski - That iiqdisabled attribute looks promising. We’ll play with that, thanks!

9

Happy to help! Let us know if that works for your use case.