Provisioning issue with WebServices Connector

fatimahm · May 7, 2025, 8:23pm

Hello,

I’m facing an issue during account creation with the Web Services Connector.

I have two entitlement types (roles/entities) and I’m using beforeOperation rules with both operations “Add entitlement-roles” and “Add entitlement-entities”.

The account creation is triggered by an access request. If we suppose the following access profiles are requested:

Access profile 1: role 1, entity 1
Access profile 2: role 2, entity 2

Both access profiles are assigned. The entities 1 and 2 are both provisioned. However, only one of the roles is provisioned (the beforeRule linked to “Add entitlement-roles” is only executed once).

In case I request one access profile, only the entity is provisioned (and the beforeRule linked to “Add entitlement-roles” is not executed).

For an existing account, the provisioning works as expected, regardless of the number of access profiles requested.

Thank you in advance for your support!

Sivakrishna1993 · May 8, 2025, 12:52am

When an account is being created, IdentityNow (and the Web Services connector) tries to optimize provisioning by collapsing operations. This can lead to beforeOperation rules not firing for each individual entitlement under certain conditions.
Assuming this behavior is only observed during account creation, not on existing accounts

This is due to how IdentityNow batches provisioning changes during account creation, often combining entitlements of the same type into a single provisioning plan step.

The Web Services connector, unlike some others (e.g., AD or SCIM), does not always split entitlement operations into individual operations when provisioning a new account. This means:

If multiple role entitlements are added, the connector might group them into a single operation.
Your beforeOperation rule for "Add entitlement-roles" runs only once, processing just one entitlement (usually the first one).
The other role entitlement(s) are not processed properly unless manually split.

Solutions

Option 1: Adjust the beforeOperation rule to handle multiple entitlements

Ensure that your beforeOperation rule handles all entitlements of type role in the plan step, even if only called once.

java List<Map> entitlements = (List<Map>) plan.getEntitlements(); for (Map entitlement : entitlements) { if ("role".equals(entitlement.get("type"))) { // Process each role here } }

This assumes the connector sends all requested roles in one Add entitlement-roles step, which your rule can loop over.

Option 2: Use afterOperation instead

If beforeOperation proves unreliable during account creation, consider moving your logic to an afterOperation rule instead. Sometimes the Web Services connector behaves more predictably with afterOperation, especially during grouped operations.

Option 3: Split provisioning plans manually in a custom workflow

If you are using workflows to create accounts or orchestrate provisioning, you can split the entitlement provisioning into separate operations — though this adds complexity and is not always necessary.

Recommended Debugging Step

Add logging inside your beforeOperation rule to print:
The number of entitlements in the plan - Their name and type
This will confirm if all roles are being passed but not processed, or if they’re missing entirely.

sauvee · May 8, 2025, 8:46am

Would this setting (only available via the API) not be a solution to your issue:

This will split up the provisioning of each entitlement, allowing one operation to be executed per entitlement being assigned, even if through the same Access Profile.

fatimahm · May 8, 2025, 9:04am

Thank you, @Sivakrishna1993 for the detailed explanation. I understand the issue better now, even though I’m confused why this only happens for the role type and not for entities.

Before proceeding to explore the proposed solutions, I wanted to share the provisioning plan that I obtained from the logs, where we can see all the types of entitlements. However, as per my understanding, they are not grouped in the same provisioning plan for the same entitlement type.

In the case of requesting only one access profile:

Dumping Provisioning Plan details  : 

<ProvisioningPlan nativeIdentity="FirstN LastN (ID))">
  <AccountRequest application="Source [source]" op="Create">
    <AttributeRequest name="entities" op="Add" value="3"/>
    <AttributeRequest name="RolesProducts" op="Add" value="A-1"/>
    <AttributeRequest name="attribute1" op="Add" value="XXX"/>
   <AttributeRequest name="attribute2" op="Add" value="XXX"/>
   ....

In the case of requesting two access profiles:

Dumping Provisioning Plan details  : 
<ProvisioningPlan nativeIdentity="User 2 (ID)">
  <AccountRequest application="Source [source]" op="Create">
    <AttributeRequest name="entities" op="Add" value="4"/>
    <AttributeRequest name="RolesProducts" op="Add" value="T-2"/>
    ...

Dumping Provisioning Plan details  : 
<ProvisioningPlan nativeIdentity="User 2 (ID)">
  <AccountRequest application="Source [source]" nativeIdentity="98" op="Modify">
    <AttributeRequest name="entities" op="Add" value="3"/>
    <AttributeRequest name="RolesProducts" op="Add" value="A-1"/>

For example above, the following entitlements have correctly been provisioned:

entities: 3 and 4
roles: A-1

After the creation, the role T-2 is displayed in ISC as “assigned” (until a next aggregation) but not in the app

Thank you

fatimahm · May 8, 2025, 9:07am

Thank you @sauvee for your response. Endeed, this already has been enabled. Otherwise, we’re getting prov errors

Sivakrishna1993 · May 8, 2025, 9:22am

Hi

I forget to ask you have you checked is any tag in the source ‘with entitlement req’ is true?

If you are passing the entitlements in seperate operation then it should be false.

Thanks,
Siva.K

fatimahm · May 8, 2025, 11:23am

Indeed, it’s false

"createAccountWithEntReq": false

baoussounda · May 8, 2025, 1:15pm

Hi @fatimahm

Based on your giving provisionning plan it seems like for Create Account Operation only one enttilement operation is executed. And as entitie is the first value on your access profiles so ISC process only that.

For example if you request Three Access Profiles (for new account) you will see that you have three entities and two roles. Just to confirm can you test that ?

fatimahm · May 8, 2025, 2:44pm

Hi @baoussounda, thank you for the response !

Indeed, the role that is supposed to be provisioned with the “Create” operation is not. The role prov only works with the “Modify” operation.

The test: I provisioned the following access proifles:

AP 1: entity “4” + role “T-2”
AP2: entity “3” + role “A-1”
AP3: entity “5” + role “A-2”

All entitlement have been prov except the role “T-2”

What I have in the pp:

Dumping Provisioning Plan details  : 
<ProvisioningPlan nativeIdentity="User1 (ID1)">
  <AccountRequest application="Source [source]" op="Create">
    <AttributeRequest name="entities" op="Add" value="4"/>
    <AttributeRequest name="RolesProducts" op="Add" value="T-2"/>
	...
  </AccountRequest>
</ProvisioningPlan>


Dumping Provisioning Plan details  : 
<ProvisioningPlan nativeIdentity="User1 (ID1)">
  <AccountRequest application="Source [source]" nativeIdentity="102" op="Modify">
    <AttributeRequest name="entities" op="Add" value="3"/>
    <AttributeRequest name="RolesProducts" op="Add" value="A-1"/>
	...
  </AccountRequest>
</ProvisioningPlan>

Dumping Provisioning Plan details  : 
<ProvisioningPlan nativeIdentity="User1 (ID1)">
  <AccountRequest application="Source [source]" nativeIdentity="102" op="Modify">
    <AttributeRequest name="entities" op="Add" value="5"/>
    <AttributeRequest name="RolesProducts" op="Add" value="A-2"/>
	...
  </AccountRequest>
</ProvisioningPlan>

Thank you

fatimahm · May 9, 2025, 10:19am

@baoussounda Could you please tell me what the purpose of the requested tests was? Can the results give us any clues? Thank you

baoussounda · May 9, 2025, 12:20pm

Hi @fatimahm

Yes the test is what i expected and as you said there are a problem on Create Account Request which not triggered correctly all entitlements request included on create account operation but only the first one.

It is not depending on specific entitlement operation i think and entity is processed because it is the first one.

But I don’t know why this behavior.