GUID Generation via Identity Attribute Rule in SailPoint – Feasibility Without Core Target System

[praveen_s_subramanian (Praveen Subramanian)]

We are working on a ISC implementation where employees are sourced from Auth and contractors via the SailPoint NELM module. We need to generate GUIDs for both existing and incoming identities using the format:
<First letter of First Name> + <First letter of Middle Name> + <First letter of Last Name> + 5-digit random number
Example: FML12345

SailPoint Options Considered:

1. Identity Attribute Generation

2. Account Provisioning Generation (SailPoint recommended)

Unfortunately, Option 2 is not viable for us since it requires provisioning to a core target system (e.g., AD), which our client does not have. We proposed using a database as a pseudo-core system, but the client prefers Option 1.

Question: Given SailPoint’s recommendation against using Identity Attribute rules for GUID generation due to potential race conditions and lack of uniqueness guarantees, is Option 1 still a feasible approach for our use case?

Constraints:

• No core target system available.

• GUID must be unique and persistent across identity refreshes.

• Rehire and conversion scenarios must reuse historical GUIDs.

[daltonherriman]

Hey Praveen,

Option #1 is feasible, but we need to accept that it cannot provide a hard, transactional guarantee of uniqueness by itself.

• This is because identity-attribute calculations are re-run and multi-threaded, so race conditions and collisions are possible

The official recommendation from SailPoint is to generate unique values at account creation on a target system (e.g., AD).

• This is where locking/uniqueness checks can actually be enforced

However, as you stated, this option isn’t available. SailPoint recommends against identity-attribute generation for uniqueness because:

• Identity attributes computed by transforms/rules are re-run during profile refresh. This means that naive generation logic can change values unintentionally unless you explicitly “freeze” the old value
• The calculation pipeline is multi-threaded, so any “check-then-set” uniqueness logic in a rule can race with another identity and produce duplicates
• SailPoint wants us to do these uniqueness checks in account create profiles (e.g., Username Generator/Attribute Generator) which include built in uniqueness checks against the target system or the ISC account store

Here is a plan that would make Option #1 workable (with constraints):

1. One-time backfill for existing identities (guarantee baseline uniqueness)

   1. Export all identities
   2. Generate GUID = <5-digit> offline with deterministic + dedupe algorithm
   3. Import back to ISC and set a custom identity attribute (e.g., companyGuid)
   4. Never recompute once the attribute is set

2. For new joiners (employees via Auth source, contractors via NERM

   1. Attach a cloud “identity attribute” rule to the identity profile that does the following:
      1. Returns old value if it exists (freeze the GUID on refresh/recalc

   
   if (oldValue != null && oldValue.toString().trim().length() > 0) {
       return oldValue;
   }
   

   1. 1. else: compute a candidate using:
         1. prefix = firstInitial + middleInitial + lastInitial (handle null/blank middle name gracefully

         2. String first = (String) identity.getAttribute("firstname");
            
            String middle = (String) identity.getAttribute("middlename");
            
            String last = (String) identity.getAttribute("lastname");
            
            String fi = (first  != null && first.length()  > 0)  ? first.substring(0,1).toUpperCase()  : "X";
            
            String mi = (middle != null && middle.length() > 0) ? middle.substring(0,1).toUpperCase() : "X";
            
            String li = (last   != null && last.length()   > 0) ? last.substring(0,1).toUpperCase()   : "X";
            
            String prefix = fi + mi + li;
            

         3. deterministic 5 digit: derived from a person key: (e.g., HR person number for employees, NELM accountName/unique ID for non-employees)
            1. Example: numeric = mod( Hash( tenantSalt + personKey ), 100000 ), left‑padded to 5 digits

            2. String personKey = (String) identity.getAttribute("externalPersonId"); // e.g., HR person number or NERM accountName
               
               candidate = prefix + numeric.
               

3. Search ISC for identities already holding that candidate. If found, recalculate with a small variant (tenantSalt-1, personKey-1, etc.) up to N retries; return first available (Cloud identity-attribute rules can read the identity model to perform these checks, they just can’t enforce locks)

for (int salt = 0; salt < 20; salt++) {

    String base = tenantSalt + "|" + personKey + "|" + salt;

    long hash = Math.abs(base.hashCode()); // or a stronger hash if available

    String num = String.format("%05d", (int)(hash % 100000));

    String candidate = prefix + num;

[MattUribe]

Are you familiar with the Identity Fusion connector?

SailPoint Identity Fusion Connector

[Marketplace-Gradient] Description SaaS Connector: SailPoint Identity Fusion Legal Agreement By using this CoLab item, you are agreeing to SailPoint’s Terms of Service for our developer community and open-source CoLab. Repository Link GitHub - sailpoint-oss/colab-saas-conn-sailpoint-identity-fusion New to SaaS connectors in the CoLab? Read the getting started guide for SaaS Connectors in the CoLab. …

This is a SaaS connector available from the CoLab that is primarily used for detecting potential matches between more than one authoritative source system. However, it does offer a unique ID generator that might fit your needs.

Let me know you want more information. There is a video in the library where the connector is covered in detail.

Matt