Using an Identity Attribute to set an Account Attribute in a JDBC Source

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

I’m trying to use the value of an Identity Attribute to affect the value of an account aggregated inside a JDBC connector. Based on my testing, I’ve inferred the following

  1. Create Provisioning Policies are not triggered when an account is aggregated into a JDBC connector. This is inferred because even when trying to use static values, the value inside the account attribute is empty. This is probably triggered only when an account is created in this connector via Request or Birthright criteria or something else, but not after aggregation.
  2. Update Provisioning Policies are not triggered as well. As despite trying to link an account attribute to an identity attribute using the Create Account tab, the value populating an account will either be empty or a value from the buildmap

For context, I need to set an account’s IIQDisabled to be true or false inside a connector based on an Identity attribute. This seems to be working fine when I’m just setting it via BuildMap with map.put(“IIQDisabled”, “true”) but I can’t seem to find a trigger to reference an Identity Attribute to set this

I’m fairly sure that a cloud rule can achieve this probably using the Account Attribute Generator rule, but is that the only way to achieve this? Is it somehow possible to do this using a transform or a connector rule somewhere?

2
  1. Attribute Sync: Map the Identity Attribute with a value of “true” to the IIQDisabled attribute in the source. Enable Attribute sync for this mapping then handle the attribute request in the JDBC connector rule.
  2. Disable Account: Set the IIQDisabled attribute during the Disable operation, then handle the attribute request in the JDBC connector rule or assume that any Disable should set that attribute
  3. Workflow - Disable Account:
    1. Trigger: Identity Attribute Changed.
    2. Action: Disable Account (Same logic as #2)

Disable Account Provisioning Policy Example:

{
    "name": "Disable",
    "description": null,
    "usageType": "DISABLE",
    "fields": [
        {
            "name": "IIQDisabled",
            "transform": {
                "attributes": {
                    "name": "iiqDisabled"
                },
                "type": "identityAttribute"
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}
3

Good Day Edward!

Thanks for the response.

Attribute Sync seems to partially solve the issue; however, my main problem is having the account synchronize the attribute after aggregation automatically. Looking at the documentation for attribute sync, it seems like it won’t be triggered automatically without a workflow or so.

Regardless, this was a step in the right direction. Thank you!

4

Please go through this.

Synchronizing Attributes - SailPoint Identity Services

In a nutshell, if your HRMS aggregation results in the identity attribute change, the same change is propagated to downstream systems automatically.

Here is an excerpt from docs.

Triggering Attribute Sync Automatically

Attribute synchronization automatically syncs identity attribute changes that have occurred in Identity Security Cloud based on your organization’s attribute sync configuration. These changes are typically a result of such processes as:

  • An authoritative source aggregation updating an identity attribute.

  • A source aggregation detecting a change to an account attribute made natively in the source system. Identity Security Cloud may override this change based on the sync configuration.

  • A source account being moved, or correlated, to a different identity with different attribute values.

5

What @SandilyaKrovvidi said is correct. You do not need a workflow to trigger attribute sync. Just the fact that

Identity Attribute != Account Attribute

Will trigger the sync.