Unique Account Attribute Generation with Future Edit functionality

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

:bangbang: Please be sure you’ve read the docs and API specs before asking for help. Also, please be sure you’ve searched the forum for your answer before you create a new topic.

Hi all,

I have a specific requirement when creating a new AD account, where I need to generate a unique Display Name attribute from the possible patterns:

"$FirstName $LastName";

"$FirstName $MidLetter $LastName"; 

"$FirstName $MidName $LastName"; 

"$FirstName $LastName ${uniqueCounter}"

From just this requirement, I was expecting to use the username generator transform to get this working.

However I have received a new requirement where we need to be able to update this account attribute after creation through ISC (through workflows/forms), and provision the change to the target application.

To use attribute sync I need the Display Name attribute to be derived directly from an identity attribute, but if I do that, I won’t be able to use the Username Generator transform in the identity attribute mappings.

How can I have this functionality to update this specific account attribute that was generated with uniqueness in consideration directly in ISC?

2

You might be able to do this using Identity Attribute Generator rule

where you can leverage the sailpoint.server.IdnRuleUtil to check if an account already exists with the patterns before returning the unique value

3

Hi @ACoutinho , You can configure before provisioning cloud rule here and inside rule only you can check the uniqueness of display name with the help of below method.

public boolean isUnique(String displayName) throws GeneralException {
    return !idn.accountExistsByNativeIdentity(application.getName(), displayName);
}

you can create a separate method for iteration for unique counter something like.


public String updateDisplayname(String displayname_identity, int iteration) {
    String Displayname_temp = "";
    int maxIteration = 30;
    if (displayname_identity != null)) {
        Displayname_temp = displayname_identity + iteration";
    }
    String dn = Displayname_temp;

    if (iteration <= maxIteration) {
        if (isUnique(dn)) {
            return Displayname_temp;
        } else {
            return updateDisplayname(displayname_identity, iteration + 1);
        }
    } else {
        return null;
    }
}

here you can get the displayname or firstname and lastname identity attribute from plan :

String displayName = StringUtils.trimToNull(plan.getIdentity().getAttribute("displayName"));

so for account creation you will get the unique displayName with this method. you can pass the value of displayName from the plan itself.

For attribute sync:

since your displayName is combination of firstname and lastname if any change occurs in these attribute then only you have to sync your displayName to the account. so that also you can handle from cloud rule as inside the accountRequest you can get the attribute list from there you can check if firstname or lastname mismatch there between identity attribute and account attribute then again you can use the same methods we have create for create account and can implement the attribute sync functionality.

Note: we can customize it on identity attribute generator rule as well but as per my understanding there is a gap because displayName uniqueness should be checked on AD accounts level otherwise it may give the object already exist exception from AD.

please find some URL for reference:

Github Sample BeforeProvisioning Rule

I hope this helps!

4

I would question this “Let’s throw in additional attributes” approach. Not all requirements are good requirements. Potentially come up with a simpler systematic, and highly deterministic requirement.

5

This is not inherently supported. This configuration would mean SailPoint is the authoritative source for the display name; SailPoint is not intended to be the authoritative source for attributes. It is intended to get the values from some other source, like the HRIS system or Active Directory. Ideally, you’d use the Preferred Name from the HRIS system as the display name (reverting to Legal Name if Preferred Name is not populated), and users would be able to update their Preferred Name in the HRIS system as-needed.

6

Hi @ACoutinho you can use generator while creating the accounts.But if you think an attribute is there at sailpoint which can be used to update this later on modify operation.You can configure the attribute sync using API .

This will help you use generator initially but later this attribute can also be updated using identity attribute

7

Hi @ACoutinho,

You can use the Identity Attribute Generator rule. It will work in both scenarios:

  1. While creating new accounts

  2. During name changes or attribute synchronization