Retrieving Account Attributes in JDBC Provision Rule

[sjoyee (Jo Yee Siang)]

Hi all.

For JDBC Disable Operation, I would need to insert a new row with all the access values to be disabled into the respective columns in the database table. Can I have some input on how to retrieve the account attributes in JDBC Provision Connector Rule?

It seems that it will be a null value from the attribute request (attrReq) from account request for disabled operation, which is what we have tested in JDBC Provision Connector Rule:

AttributeRequest attrReq = accountRequest.getAttributeRequest(“access_group_attribute”);

Please advise. Thank you!

[venkateshkan (Venkatesh Kandimalla)]

For Disable operation, by default your entitlements are not part of the plan to be removed, you would see only an account request with Disable operation. Hence, your code is returning null. Since JDBC Provisioning rule is a connector rule, you might not have the identity data as well to get the required information. One workaround you can try is to get the user access information from the database and process them to be removed by inserting into the new table.

Regards,
VK.

[sjoyee (Jo Yee Siang)]

Hi VK,

Thanks for the input. Let’s say we also have some other account attributes (copied from identity attribute and not entitlements) to be inserted in the row during the disable operation, is there a way to insert these account attributes to the account request for JDBC connector?

Or a way to retrieve account attributes, let’s say using a before provisioning rule?

[iamnithesh (Nithesh Rao)]

If you need to include any identity attributes that are not the part of provision plan, then

• you need to do the same in Before Provisioning (cloud) rule as identity object is not available in connector rules.
• add these attributes to the Provision Plan using attribute names specified in the account schema
• if you do not have a suitable account attribute specified in the account schema, then you can use plan arguments to ship the values to connectors

[venkateshkan (Venkatesh Kandimalla)]

You could leverage the Disable provisioning policy in this scenario. Add whatever attributes you require in the policy and they should be automatically added to your plan.

Regards,
VK.

[sjoyee (Jo Yee Siang)]

Hi VK,

Thank you very much for the advice. We have updated the provisioning policy with DISABLED as the usageType via V3 API, however it seems that it is still inserting null, after double checking the accuracy of the spellings of the account and identity attributes and updating on the correct source. Is there any extra step that we might miss here?

I have included the example code and config we have done as follows to show a clearer picture.

Provisioning Policy:

{{baseUrl}}/v3/sources/:sourceId/provisioning-policies/:usageType

JDBC Provision Rule:

public String getAttributeRequestValue(AccountRequest acctReq, String attribute) {

    if ( acctReq != null ) {
        AttributeRequest attrReq = acctReq.getAttributeRequest(attribute);
        if ( attrReq != null ) {
        return attrReq.getValue();
        }
    }
    return null;
}

For Disable Operation,

PreparedStatement statement = connection.prepareStatement
    (
        "insert into Test_Table (id,account_attribute_a,account_attribute_b) "+
        "values (?,?,?);"
    );
statement.setString (1, (String) account.getNativeIdentity()); 
statement.setString (2, getAttributeRequestValue(account,"account_attribute_a"));
statement.setString (3, getAttributeRequestValue(account,"account_attribute_b"));

We manage to only insert the native identity at the first column “id”, but null for the rest of the values (which we have added into the provisioning policy).

[sjoyee (Jo Yee Siang)]

Hi Nithesh,

Thank you for the input.

Just to confirm, do you mean that even the account attributes to be inserted in the DB table exists in the account schema, I will still need write a Before Provisioning Rule as follows to get the attribute retrieved from the identity, and add it to the Provision Plan using the attributes name specified in the JDBC source account schema?

We are trying to see all the possibilities since if it is possible to do via V3 API by updating the disable provisioning policy, then we would not write the cloud rule for review and deployment.

The code which I understand from your input is as follows:

if (op.equals(AccountRequest.Operation.Disable)) {

    accountRequest.add(new AttributeRequest(
        "account_attribute_a", 
        ProvisioningPlan.Operation.Set,
        identity.getAttribute("identityAttrA"))
    );

}

where account_attribute_a is the attribute name specified in the JDBC source account schema.

Do correct me if I understand wrongly, thank you very much!

[iamnithesh (Nithesh Rao)]

Sorry I misread your earlier post and thought you wanted to update the DB table with values from identity attributes.

If what you want to insert are account attributes and they have been specified under “Create Profile” Policy, then they will be automatically included in the ProvPlan during “Create Account” Operation only. They will not be included in the ProvPlan in other cases (of course with the exception of “Update” operation where changed account attributes will be included provided they are assigned Identity Attributes in the ProvPolicy and checked to be included in Account Sync)

In your case, where account is being disabled, you may have to use Link object to get the specific account and get the necessary attributes to be added to the provision plan. This has to be done in Cloud rule as you cannot access Link in Connector rule (at least to my best knowledge). Once they are included in the ProvPlan you can read them in the Connector Rule using standard Account Request > Attribute Request > Attribute Value relationship, and then assign each of them to a variable and then use in your SQL query.

Hope this helps

[sjoyee (Jo Yee Siang)]

Hi Nithesh,

Sorry for the confusion, I updated the code in my previous response, not seeing your latest reply to me.

Since the account attributes to be inserted on my side are mostly copied from identity attribute, will like to confirm:

If we go via the identity attribute route, is this what you were suggesting to me?

if (op.equals(AccountRequest.Operation.Disable)) {

    accountRequest.add(new AttributeRequest(
        "account_attribute_a", 
        ProvisioningPlan.Operation.Set,
        identity.getAttribute("identityAttrA"))
    );

}

where account_attribute_a is the attribute name specified in the JDBC source account schema.

Meanwhile we will also explore the way using Link object as suggested, thank you!

[iamnithesh (Nithesh Rao)]

@sjoyee

If we go via the identity attribute route, is this what you were suggesting to me?

Yes. This is how you can add additional attributes to the plan.

And, here is the method you can use to get the Link specific to the account in question,

private Link getCurrentLink(Identity identity, String nativeIdentity) {
    if (identity != null && identity.getLinks() != null && !identity.getLinks().isEmpty()) {
        for (Link link : identity.getLinks()) {
            if (link.getNativeIdentity().equals(nativeIdentity)) return link;
        }
    }
    return null;
}

if (op.equals(AccountRequest.Operation.Disable)) {
   Link thisAccount = getCurrentLink(identity, nativeIdentity);
   if(thisAccount != null){
     accountRequest.add(new AttributeRequest(
         "account_attribute_a", 
         ProvisioningPlan.Operation.Set,
         thisAccount.getAttribute("account_attribute_a"))
     );
     accountRequest.add(new AttributeRequest(
         "account_attribute_b", 
         ProvisioningPlan.Operation.Set,
         thisAccount.getAttribute("account_attribute_b"))
     );
   }
}

[iamnithesh (Nithesh Rao)]

@sjoyee
Were you able to resolve your issue? An update would be appreciated

[sjoyee (Jo Yee Siang)]

Hi Nithesh,

We have deployed the before provisioning rule and my team is currently doing testing on this. Will definitely update once it is tested, thank you very much for your advice!

[sjoyee (Jo Yee Siang)]

Hi Nithesh,
Update from our findings, we try deployed the before provisioning rule using the Link object, it is working for those with account attributes which are already populated in the Create Account Policy, but null values for attributes that aren’t. For those cases, we handle it by retrieving directly from the identity attribute in the Before Provisioning Rule as suggested as well, and they are working fine now, thank you for the input!

[iamnithesh (Nithesh Rao)]

@sjoyee

it is working for those with account attributes which are already populated in the Create Account Policy, but null values for attributes that aren’t

Thanks for this feedback… I will have to dig a little deeper on this