Custom Attributes in Provisioning Plan

I have a use case of a JDBC type Source, where we need to fetch few identity attributes that are not a part of Provisioning Policy. I was wondering if we can have some attribute requests added to the Account Request inside BeforeProvisioning Rule like below
accountRequest.add(new ProvisioningPlan.AttributeRequest("someCustomName", ProvisioningPlan.Operation.Set, identity.getLastname()));
(someCustomName is not a part of Account Schema)
and then use it in JDBC Provisioning Rule
String jobDescription = (String) accountRequest.getAttributeRequest("someCustomName").getValue()

Any insights will be appreciated

Hello Nithesh,

You can indeed add to the provisioning plan from the before provisioning rule.

Consider that you can also just add it via the provisioning policy (aka account create profile) , so that you wouldn’t need a cloud rule approval.

With a JDBC provisioning rule, you are controlling the all the provisioning logic, so you can use the attributes for what you need inside of the JDBC provisioning rule but don’t need to actually provision them.

Thanks @ruben_elizondo,
A follow up question…
Can we access Identity Attributes directly in JDBC Provisioning Rule using below code?

Identity identity = plan.getIdentity();
String someAttribute = identity.getStringAttribute("someAttribute")

My understanding is that Identity Attributes are not fetchable in a Connector Rule, but a colleague of mine says it is possible in JDBC Provisioning Rule.

Appreciate your response…

Just an update on this:

I did test this possibility, and Identity identity = plan.getIdentity(); returned null for identity

@ruben_elizondo
Our use case is a little complicated as the DB we are connecting to is a proprietary one and we do not get to see the table or column names. Our client has created Store procedures and we are using a Callable Statement in our JDBC Provisioning rule. This makes it challenging to leverage Create Profile or Update Profile configuration (though not impossible and we are using it to a certain extent)

In addition to this, we need to pass all the attributes in both Create and Update operations as the Stored procedure needs them to update the row in the table. As IDN includes only updated attributes in case of Update operation, we have to add the missing attributes to the plan in the BeforeProvisioning plan. Hence, we are thinking of adding all the required attributes to the Account Request as below:
accountRequest.add(new AttributeRequest("USER_WORK_PHONE", ProvisioningPlan.Operation.Set, identity.getStringAttribute("phoneNumber"))) and read the same into a string in JDBC provisioning Rule
String phone = accountRequest.getAttributeRequest("USER_WORK_PHONE").getValue();
where USER_WORK_PHONE is an attribute from the Create profile.

However, I am not sure if this will work when the original Account Request already has an Attribute Request for USER_WORK_PHONE, and if it does how is the duplicate Attribute Request handled in the Provision plan.

Thanks for any help

Hi Nithesh,

No, you don’t have access to the identity object in connector rules, hence the need to pass in the needed information in the policy or beforeprovisioning rule.

1 Like

Hello @iamnithesh ,

You don’t need write before provisioning rule.
Create a schema attribute “somecustom” and in create policy attach that custom attribute with identity attribute and then in JDBC provisioning rule user somecustom to get the value.

Thanks !!

1 Like

Ah, you mean what would you do if the account’s workphone is actually being updated and the workphone is one of the attributes you are adding to the before provisioning plan?

In the beforeProvisioningRule, you can first interrogate the provisioning plan to see what attributes are already in the plan. Then add in the attributes you need for the stored procedures that are lacking so that you won’t have to deal with overriding or duplication.

I believe it will override but I don’t remember that specific scenario. You could turn on logging for the jdbc provisioning rule and observe the plan that the beforeProvisioningRule has already modified to confirm. They will be visible in the /log/ccg.log of the VA using this logger.

logger.JDBCConnector.name = sailpoint.connector.JDBCConnector
logger.JDBCConnector.level = debug
logger.JDBCConnector.additivity = false
logger.JDBCConnector.appenderRef.rolling.ref = STDOUT

For Reference: CCG Enable Debug Log by Connector - Compass

-Ruben

1 Like

Thanks Prasad,
Though your suggestion will work, this will not be a feasible solution to our situation

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.