IDHUB | Usernames Best Practices
- 09 Aug 2023
- 1 Minute to read
- Print
- DarkLight
IDHUB | Usernames Best Practices
- Updated on 09 Aug 2023
- 1 Minute to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
To balance ease of use with industry best practices around usernames, please consider the following.
Best Practices for Usernames
- First Initial, Last Name
- First Name, separator character (e.g. period, underscore), Last Name
- Combination of name with a unique identifier (NOT SSN or part of SSN)
- A unique identifier such as employee ID or student ID (NOT SSN or part of SSN)
Things to take into consideration with username policies:
- If the source system (e.g. SIS or HRMS) generates a username that the user will already know, then that can be used if desired.
- Username Collision
- ID Hub will automatically append an incrementing counter to usernames that conflict (e.g. if two users are named John Smith, you will have jsmith and jsmith1).
- If this is not desirable, the formula for creating the username should be adjusted to ensure uniqueness (e.g. by importing the username from SIS or HRMS, or by using a unique identifier within the username).
- ID Hub will automatically append an incrementing counter to usernames that conflict (e.g. if two users are named John Smith, you will have jsmith and jsmith1).
- Username Delivery:
- Consider how the end user will learn what their username is.
- When the username is formulaic and unique (e.g. when it contains their ID number), you can provide generic instructions to all users.
- You can leverage QR ID Badges in place of usernames for RapidIdentity authentication. However, the username will still end up in target systems.
- Otherwise, this information will have to be provided to users by some manual process.
- Complexity
- Users should not be forced to remember something overly complex to log in. This can lead to unnecessary frustration with the new system.
- ID Hub will not automatically rename accounts as part of your normal provisioning process. Consider this if you map a username from the source system and that value can change. This value will not automatically flow to target systems for existing users that are updated.
Was this article helpful?