Knowledge Article

Best Practices - Generating Usernames in IdentityNow

Author

neil_mcglennon
SailPoint

Overview

As part of most provisioning processes, often it is necessary to generate unique usernames for accounts during provisioning. This document outlines the most common ways to approach username generation, and some of the trade-offs between the various approaches.

Account Provisioning Generation

Use Case

In this approach, a username is not generated as an identity attribute, but a username is generated at account provisioning time, should a user account need to be created.

Details

When an identity first comes into IdentityNow, an identity is created based on data from an authoritative source (like an HR source). Its attributes are calculated, and there are no usernames present, instead using unique identifiers from the authoritative source.

Once the identity is built, role and lifecycle states then dictate what accesses are granted — if any. If access is granted on a particular source system, then those requests go through IdentityNow's provisioning processes. As part of this process, if an account does not yet exist, an account will created and provisioned for that identity. For account creation, an account creation profile dictates the provisioning policies for generating account attributes, including username generation.

One of the key differences in the approach here, is that of uniqueness checking. First, the username generators (and rules) have the ability to query account data within IdentityNow, to determine if a proposed username exists as an aggregated account or not. In addition, the username generators (and rules) have the ability to query account data directly on the source system, to determine if a proposed username exists as an account or not. This last approach is a distinct advantage of generating usernames via account provisioning.

When comparing an account creation process to an identity attribute calculation process, there tends to be less in flight at a given time, so we can consider this to be less multi-threaded. Because of these, you are statistically less likely to run into race conditions when generating usernames via this approach.

After the provisioning of new accounts and usernames is carried out, the identity attributes can then be updated to reflect that there is a preferred username, over the initial one that was determined by the authoritative source. Implementers commonly use a first-valid transform for this purpose.

If additional accounts or sources rely on using the generated username, then special care may be taken in consideration to handle provisioning dependencies appropriately. You may want to only provision other source systems or assign other accesses after you already have a username provisioned on your core system (e.g. directory).

Advantages

As-needed. Only generated or reserved for identities which need accounts created.
More accurate. Uniqueness checks against account data in IdentityNow and / or via source directly.
Less likely to be affected by race conditions.
Does not require a rule, if using out-of-the-box generators.

Disadvantages

Requires some planning and fore-thought, especially around provisioning dependencies.

Other Considerations

Leverage first-valid transforms on the identity to determine which usernames are most important, in which order.

Identity Attribute Generation

Use Case

In this approach, a username is generated as an identity attribute, and all subsequent account provisioning leverages that generated identity attribute.

Details

When an identity first comes into IdentityNow, an identity is created based on data from an authoritative source (like an HR source). Its attributes are calculated, and during this process a username is generated for the identity, if one does not yet exist. This username generation has to be carried out by identity attribute rules, and is done for all identities, regardless of if an identity requires a username or not.

For uniqueness checking, the identity attribute rules can only query account data within IdentityNow to determine if a proposed username exists as an aggregated account or not. The identity attribute rules do not have the ability to query account data directly on the source system, which means that accuracy is limited to how often accounts are aggregated.

The identity attribute calculation process (aka identity refresh) is a massively parallelized, multi-threaded process. There tends to be a lot in-flight at a given time, and more likely to run into race conditions when generating usernames via this approach. For example, if you had three identities all named John Smith, they may all be processed simultaneously in parallel threads, and each thread could arrive at same username conclusion at the same time.

If additional accounts or sources rely on using the generated username, then they simply just refer to the identity attribute in the account profiles; there is no need to take in consideration provisioning dependencies on username alone. This can still lead to provisioning failures if the username is already used on the source system.

Advantages

More straight-forward to understand and execute.

Disadvantages

Access independent; usernames are generated for everyone regardless if they need it or not.
Less accurate due to dependencies on aggregated data. Uniqueness checks against account data in IdentityNow only; not via source directly.
More likely to be affected by race conditions, due to heavy parallelization.
Requires an identity attribute rule to be implemented.
Blindly creating usernames increases likelihood for provisioning creation failures.

External Username

Use Case

In this approach, some sort of (presumably) unique attribute is given to IdentityNow to be used as a unique identifier. This is common for organizations which do not want to generate usernames, but instead re-use existing identifiers (e.g., employee number).

Details

When an identity first comes into IdentityNow, an identity is created based on data from an authoritative source (like an HR source). Its attributes are calculated, and during this process a unique identifier, such as employee number, is promoted to the identity as the username identity attribute.

Advantages

More straight-forward to understand and execute.
No uniqueness checks needed.
Can be implemented with simple attribute mapping.

Disadvantages

Access independent; usernames are generated for everyone regardless if they need it or not.
Blindly creating usernames increases likelihood for provisioning creation failures.
Requires this logic to be placed outside of IdentityNow, and some HR systems may not have this ability.
Complicates authoritative source migrations, where employee identifiers (and thus usernames) may be drastically different.

Recommendation

Of the three most common options highlighted here, generating a username during Account Provisioning Generation is the preferred best practice approach by provisioning implementations. This is the approach over 90% of SailPoint customers use, and consequently is the default best practice approach for implementation in IdentityNow. While it does require some planning, it offers the most integrity, most flexibility, and doesn't put the onus for unique usernames (via identifiers) on upstream authoritative sources. While we don't recommend Identity Attribute Generation because of its lack of flexibility and integrity in uniqueness, it certainly can have its place in smaller less-complex implementations.