Why does attributes set in JDBC modify account provisioning policy not come up in provisioining plan in IDN

[RohanBhat10 (Rohan Bhat)]

Hi Team,

I was working on onboarding a new JDBC source in my tenant. As part of this I have attached a modify account provisioning policy to the source with “usageType”: “UPDATE”, but I not see the attributes added in the provisioning policy coming in the provisioning plan when there is modify account request. I had found a work around and I just queried the target database itself to get the required user attributes in my provisioning plan, but this has a technical downside and I cannot use this anymore. So I need these attributes to come in the provisioning plan itself when IDN creates the proivisioning plan for modify account requests.

Below is the provisioning policy attached to the source. I do not know why the attributes mentioned here are not coming in the provisioning plan. Any help is greatly appreciated.

{
“name”: “Modify Account”,
“description”: “Some Name”,
“usageType”: “UPDATE”,
“fields”: [
{
“name”: “USER_ID”,
“transform”: {
“type”: “identityAttribute”,
“attributes”: {
“name”: “loginName”
}
},
“attributes”: {},
“isRequired”: true,
“type”: “string”,
“isMultiValued”: false
},
{
“name”: “USER_NAME”,
“transform”: {
“type”: “identityAttribute”,
“attributes”: {
“name”: “displayName”
}
},
“attributes”: {},
“isRequired”: true,
“type”: “string”,
“isMultiValued”: false
},
{
“name”: “USER_EMAIL_ADDRESS”,
“transform”: {
“type”: “identityAttribute”,
“attributes”: {
“name”: “email”
}
},
“attributes”: {},
“isRequired”: true,
“type”: “string”,
“isMultiValued”: false
}
]
}

[ksbagade (Kartik Bagade)]

Hi @RohanBhat10,

Is this in use with the JDBC Provision Connector rule?

[vguleria (Vikas Guleria)]

Hi @RohanBhat10 ,

I have also seen such behavior in webservice based connectors and my case the provisioning policy was able to populate only the attributes which were actually modified in ISC. So in your case, i believe for example if the identity attribute email or displayname is changed, then you will see the attribute USER_EMAIL_ADDRESS or USER_NAME attribute populating respectively in the provisioning plan. But i had seen this behavior quite some time back and then used the same approach you mentioned i.e. query the target application and then populate the attribute manually if they are not available already in the plan.
I too agree that this is not ideal behavior but i got the feedback that it is a standard behavior probably to maintain the performance and ensuring that all attributes are not getting updated every time so may be you can also test by changing the email or display name attribute and then see if in that case these attributes are available in the provisioning plan.

I hope this helps.

Regards
Vikas.

[jesvin90 (Jesvin Joseph)]

Hi @RohanBhat10,

You will need to rely on a before provisioning rule to pass the attributes. Take a look at the below blog post :

Pass Non-Provisioned Attributes from Before Provision rule to Connector Rules

[header-image] Introduction A common use case when developing for provisioning is the need to provide information to a connector rule that is not available on the virtual appliance (VA). This can occur because you need identity information to perform additional logic, or because a request payload requires information that is not actively changing in the account. The first case can often occur in Active Directory and Azure Native Rules, where a developer must take additional actions based on…

[RohanBhat10 (Rohan Bhat)]

Hi @ksbagade,
Yes, this is in use with JDBC Provisioning Rule attached to JDBC connector. In the rule I had to pull these attributes to provision it to the target database. I am querying the target database at the moment as a work around to get user details, but it failes if there are no entries in the target database. So I had to rely on the Update provisioning policy.

[RohanBhat10 (Rohan Bhat)]

hi @vguleria,
Thanks for the udapte!

I think I did not clearly tell you the requirement, sorry for that.
Our requirement was, whenever we request any role to a user, we have to create a fresh entry in the target database, so for examply if the user is requesting access for the first time, it comes as create account in the plan and all the attributes indeed come as part of create account provsioning policy and then a new entry is added in the target database with these values. Next time when user requests another access, it comes as modify account operation and the plan only holds the attribute for the entitlement being added and not other attrbutes such as email or user_name, but these are needed for to add the entry in the target database.

So in my case I am not trying to syn the attribute. Infact I need attributes coming inside the paln as part of the access request.

I just noticed there is usageType:“UPDATE_GROUP” for provisioning policy. I am not really sure what does this do as there is no explaination for this type in the API doc.

[RohanBhat10 (Rohan Bhat)]

Hi @jesvin90,

Thanks for the update. I really apprecaite your response and the blog is really useful and informative.

I will use this approach if there are no other ways to retrieve the information, I mean by provisoining policy.

As you know, before provisioning rule is a cloud executed rule. Unfortunately we cannot directly write this rule and update it to the tenant ourselves. So we have to rely on Sailpoint expert services to attach this rule and to test it, for this we need to opt for expert services help which is chargable We would like to avoid this and rely on this as a last resort.

[jesvin90 (Jesvin Joseph)]

Hi @RohanBhat10,

You can also make use of the Services Standard BeforeProvisioning Rule and add arguments to it in the event configurations as below :

{
“Action”: “AddArgument”,
“Attribute”: “mail”,
“Value”: “#{identity.email}”
}

Here is the link to the details of the mock project.

This rule can even be deployed with the sp-config functionality without the need for Expert services.

[vguleria (Vikas Guleria)]

Hi @RohanBhat10

Thank you for explaining the requirement. Indeed I thought that the issue occurs during update of the account.
For role assignment I believe we should make use of usage type ASSIGN as per below documentation.

get-provisioning-policy | SailPoint Developer Community.

But I have not been able to manage to populate the identity attributes in the provisioning plan during access request except of entitlement information so do not think that should help.
But we already have @jesvin90 here whose contribution to the community have been wonderful so I think it will be wise to make use of his valuable suggestions and that should help in your case.

Thank you
Regards
Vikas

[jsosa (Julian Sosa)]

Hi Rohan, I have had this problem in the past. It relies in that provisioning policy update only establish the “maps”, but when you are in “code” you will receive only updated attributes. You can put any number of attributes in the update provisioning policy, but only receive the ones that are changeing it.

I solutioned in a way that I do not if is right for you, but I left you here. Basically, what I id is add a fake attribute in the update provisioning policy (you can name as you want).

This attribute value is a concatenation of:

1. random number transform
2. attributes to use, concatenated with some separator

This was usefull too, in order to use some identity attributes or attributes from other sources, that are not mapped in the connector. It will always bring the attributes, no matter they change or not (I guess that as it begins with the random number, connector interprets as if it is always changing its value).

To use it in your coude, simply read this attribute value, extract the random number part, and split concatenated attributes by its separator.

A secondary effect I found is that I received the update event twice, but in my case it did not impact at all on functionality (as attribute on source was updated twice with the same value).

[gmilunich (Geoff Milunich)]

@jsosa I have a couple questions related to your approach:

• How do you keep the update from running each time if the attributes always change with the random number?
• Does your update policy also have the original attributes as well and the fake ones?
• Does each real attribute need to have a fake one as well?
• Are there differences in the 2 update events that you receive?

If I understand correctly, you are getting the updates triggered (I assume) by an attribute sync event, which triggers on a real attribute change, and then when it calculates the update plan using the policy, it adds the changed “real” value, and all of the “fake” attribute values for the remaining fields that you need, correct?

[jsosa (Julian Sosa)]

Hi Goeff! To be honest, I could not understand completely the IDN logic regarding the update event comes through the rule. What I did is to have a unique attribute, which starts with some random number, followed of some needed attribute values, concatenated with some string.

Something like this:

{
    "name": "Account",
    "description": null,
    "usageType": "UPDATE",
    "fields": [
        {
            "name": "IDNATTRIBUTES",
            "transform": {
                "attributes": {
                    "values": [
                        {
                            "attributes": {
                                "length": "4"
                            },
                            "type": "randomNumeric"
                        },
                     "-",
                      {
                        "attributes": {
                            "name": "email"
                        },
                        "type": "identityAttribute"
                      },
                      "-",
                      {
                        "attributes": {
                            "attributeName": "sAMAccountName",
                            "sourceName": "Active Directory"
                        },
                        "type": "accountAttribute"
                      }
                    ]
                },
                "type": "concat"
            },
            "attributes": {
                "cloudRequired": "true"
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

Then, in the jdbc provisinoing rule:

String IDNATTRIBUTES = (String) accountAttributes.get("IDNATTRIBUTES");
String[] idnattributes = IDNATTRIBUTES.split("-");
String identityEmail = idnattributes[1];
String adLogin = idnattributes[2];

Common sense tells that it will always keep running, but I only receive 2 update events.

To answer the other questions,

2. the update policy only have this random+attributes fake attribute, as it always comes with actual value. I did not need to bring other attributes as they come inside this concatenated “super” attribute.

3. in my case, as in (2), I did not need to have the real attributes, because they come with this “super” attribute, after random number.

4. there were no difference in the attribute values, only the random number, for example:
   update1: attribute=1234+value1+value2+…
   update2: attribute=4567+value1+value2+…
   It ended sending 2 updates to source… but as it is with the same values, worked for me.

Finally, as only this fake attribute is on the update provisioning policy, it really does not have anything checked in the sync attributes screen.

What I guess (only a guess), is that when some of the attributes contained in the fake attribute changes, it triggers the “sync” through the update provisinoing policy. Then, as the random number changes, this is the second occurence of the update event.

I did not found other way to implement it.