Web Services rule to reference account attribute not in provisioning plan?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

I am working on an integration with the Web Services connector and am nearly finished. However, I have run into an issue with the Disable Account operation.

For context, the application has a unique identifier (the USER_LOGIN) that is generated upon account creation. However, it cannot be retrieved from the API response when the account is created, and therefore when an aggregation is run, a duplicate account gets created with the proper nativeIdentity value, and the original one is left hanging without a nativeIdentity.

For this reason, I abandoned the idea of having USER_LOGIN be the Account ID for this source. That way, an aggregation will not create a duplicate since the Account ID is available in the provisioning plan (I used the UPN), so I can set the nativeIdentity value at the time of provisioning.

HOWEVER, this causes problems when trying to write the Disable Account operation, which requires USER_LOGIN as an input. USER_LOGIN is an attribute on the account, but now cannot be referenced with $plan.nativeIdentity$, so I have no way to pass it into this operation. Is there a rule that can be used to reference an account attribute that is not available in the provisioning plan? Basically, I need to be able to do something like $account.USER_LOGIN$, which doesn’t exist.

Also, there is no API endpoint to get a single account, so chained operation is not possible.

2

I haven’t tested this, but it seems like you should be able to create a disable policy that contains the mapping to an identity attribute. Make an identity attribute that has the USER_LOGIN value, if you don’t already have one. Then you can use $plan.USER_LOGIN$

{
    "name": "disable",
    "description": null,
    "usageType": "DISABLE",
    "fields": [
        {
            "name": "USER_LOGIN",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "attributeNameContainingUSER_LOGIN"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

Alternatively, you can create a web service before operation rule that calls an ISC API to get the USER_LOGIN value, but that’s the long way around, and should be avoided if possible.

Matt

3

@MattUribe I haven’t made a provisioning policy other than “create” before, but this seems like a really simple way to do it. Thanks for the response and I’ll let you know whether it works as expected

4

Hi @akkochman , Did you try creating a provisioning policy form for the disable account operation? If user_login attribute is the unique identifier for that application account , then how can reference it using identity attribute?
My suggestion is, when account is created, in the response you are not able to see the user_login, so just write an after aggregation rule, and fetch the newly created user by passing other attributes like email which is used in account creation, then you can see all account attributes, now map the response to the account attributes, then the user will have user_login attribute.

Now , you can directly use the $plan.user_login$ for disable account operation.