Source account provisioning with "multi-valued" identity attributes?

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

For reference, we have an LDAP instance with several multi-valued attributes that are downstream of multiple systems. Previously, in IIQ, we synthesized these as multi-valued identity attributes; now with ISC lacking the ability to have multi-valued identity attributes, we still need to be able to set them.

I’ve seen that you can set cloudDelimiter for an attribute in your source provisioning policy. I think that gets us half of the way there. I was wondering how aggregation and change detection worked with that, because we’re comparing a string to a list?

2

Hi @hooverd ,

In the account provisioning policy, you can always configure a multi-valued attribute like this:

{
            "name": "proxyAddresses",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "proxyAddresses"
                }
            },
            "attributes": {
                "cloudDelimiter": ","
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": true
        }

In this example, the proxyAddresses identity attribute should contain a comma-separated list of values, for example:

smtp:test1@test.com,SMTP:test1@test.com

This allows ISC to provision the account attribute as a multi-valued attribute during account creation.

For aggregation, make sure the attribute is defined as multi-valued in your account schema. During aggregation, ISC will correctly populate the account attribute with all values because account attributes support multi-valued data.

The main limitation comes when you need to synchronize this attribute. Unfortunately, identity attributes do not support multi-valued values. To handle this scenario, you’ll need custom logic. For example, you could implement a cloud before provisioning rule that processes the synchronization, converts the identity attribute into a multi-valued attribute, and updates the provisioning plan accordingly before the changes are sent to the target system.

3

Hello David. @baoussounda approach should cover account creation and aggregation. cloudDelimiter with isMultiValued: true should split the delimited identity value during account creation, while defining the LDAP account attribute as multi-valued in the account schema allows aggregation to store all values as a list.

For change detection:

Native Change Detection compares stored account data with newly aggregated account data, so the identity attribute string is not involved. For native updates, it should work provided Account Updates and that attribute are selected for monitoring.

Attribute Sync is different. cloudDelimiter does not make the identity attribute truly multi-valued, and the official documentation states that multi-valued sync requires custom rules.

image
image1342×230 14.5 KB

A Before Provisioning Rule can add a Set AttributeRequest containing the actual list, but it only runs after a provisioning plan exists. One documented pattern is to use a helper single-valued synced identity attribute with an Identity Attribute Rule to detect the mismatch and trigger provisioning. Dakota’s KB article describes that approach.

Also, compare the LDAP values as sets rather than ordered lists, since LDAP multi-valued attributes do not guarantee value order.