New Account creation for JDBC application through Access Request

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Could anyone please help me understand if I request multiple entitlements to create new account through access request for JDBC application, how the provisioning plan looks like. Currently, it is showing create operation for one the attribute request and for rest of the attributes request, it is showing modify. Is it something OOTB in IIQ?

2

Hi @AnuragJain78 -

Could you print the plan in XML

Thank you

3

Hi Amit,
It created the separate plan for each entitlement requested and one of them is sent with create operation and rest of them are provisioned with modify. We saw this Master plan in identityrequest object.

4

is IIQ throwing any error while processing this request?

5

It is not throwing any error but just want to understand how it behaves in case of multiple entitlements are requested by user and it requires account creation in the same request. How Sailpoint figure out which attribute request should go as create operation and which one will go as part of modify operation in JDBC global provisioning rule.

6

@AnuragJain78 -

The provisioning plan will look something like below -

<!DOCTYPE ProvisioningPlan PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<ProvisioningPlan nativeIdentity="1b2b3b4a" targetIntegration="Wintel Application" trackingId="61695b3aa9e44408be297de22ae7aa09">
  <AccountRequest application="Wintel Application" nativeIdentity="1b2b3b4a" op="Create">
    <Attributes>
      <Map>
        <entry key="attachmentConfigList"/>
        <entry key="attachments"/>
        <entry key="flow" value="AccessRequest"/>
        <entry key="id" value="c0a838668ceb119b818cec0626fb00a0"/>
        <entry key="interface" value="LCM"/>
        <entry key="operation" value="EntitlementAdd"/>
      </Map>
    </Attributes>
    <AttributeRequest assignmentId="1a2f7df707db4c9fbeeaefca7b1793de" displayValue="DPA" name="grpmembership" op="Add" value="DPA">
      <Attributes>
        <Map>
          <entry key="assignment" value="true"/>
        </Map>
      </Attributes>
    </AttributeRequest>
    <AttributeRequest assignmentId="e26604276bee415ca821db329dc85cb2" displayValue="PayrollAnalyis" name="grpmembership" op="Add" value="PayrollAnalyis">
      <Attributes>
        <Map>
          <entry key="assignment" value="true"/>
        </Map>
      </Attributes>
    </AttributeRequest>
    <AttributeRequest name="userName" op="Set" value="[email protected]"/>
    <AttributeRequest name="Inactive" op="Set" value="False"/>
    <AttributeRequest name="empID" op="Set" value="1b2b3b4a"/>
    <AttributeRequest name="Manager" op="Add" value="c0a838668c661054818c662db1ec0112"/>
  </AccountRequest>
  <Attributes>
    <Map>
      <entry key="identityRequestId" value="0000000123"/>
      <entry key="requester" value="spadmin"/>
      <entry key="source" value="LCM"/>
    </Map>
  </Attributes>
  <Requesters>
    <Reference class="sailpoint.object.Identity" id="c0a838668c61120e818c6113437800eb" name="spadmin"/>
  </Requesters>
</ProvisioningPlan>

You can attach similar beforeProvisioning Plan to your application to print the plan in XML.

/*******
 *                                                                                    *
 * Generated: Tue Jan 02 18:23:38 PST 2024                                            *
 * Rule: Before Provisioning Rule Template                                            *
 * Description: Before Provisioning Rule Template                                     *
 * Inputs:                                                                            *
 *     plan - The ProvisioningPlan object on its way to the Connector.                *
 *     application - The application object that references this before/after script. *
 * Returns:                                                                           *
 ******/
import org.apache.log4j.Logger;
import sailpoint.object.ProvisioningPlan;
Logger logger=Logger.getLogger("com.amit.rules");

logger.info("Entering the Before Provisioning Rule::Database beforeProvisioningRule");
logger.info("Printing the system generated Provisioning Plan in XML\n");
logger.info(plan.toXml());

Thanks

7

Thanks Amit for the prompt response. I have the same understanding but if I see my identityRequest object, I could see that a separate plan has been created for each attribute request. For one plan the accountRequest operation is create and for other it is modify. So, is it something out of the box or do we handle it somewhere in custom logic?

8

@AnuragJain78 -

I think you are confusing yourself. The Identity Request Initialize subprocess performs several important functions:

  • Compile the provisioning plan into a provisioning project
  • Create the approvalSet which will be used to track approval decisions for the request
  • Check the request against active policies for policy violations
  • Audit the start of the provisioning process
  • Create and begin populating the identity request
  • Gather any supplemental provisioning data required from the requester

Hence what you are seeing is an expanded version of the original plan that gets passed into the Workflow.

Attach the above mentioned before provisioning plan to your JDBC application and print the plan and then compare with the IdentityRequest plan, you will see the difference.

import org.apache.log4j.Logger;
import sailpoint.object.ProvisioningPlan;
Logger logger=Logger.getLogger("com.amit.rules");

logger.info("Entering the Before Provisioning Rule::Database beforeProvisioningRule");
logger.info("Printing the system generated Provisioning Plan in XML\n");
logger.info(plan.toXml());

Thank you!