The Network or Domain UserId is your most used Id. There is no set standard for generation of the UserId except that it should be unique. The discussion here applies to any IT system which has an Authentication and/ Authorization module. In many cases the Active Directory/ Azure Id is used for authentication and authorization to various systems.
UserID generation algorithm options
1. Use FirstName and LastName combination with an optional special character. e.g. Aaron.Nichols. When the 2nd person with same First, last name joins you append a sequential number (Aaron.Nichols1). This works fine till one of the Aaron's is terminated at which point you have the option of reusing the Id for the next person or just generating a new one. Reusing lets you keep the number lower with time as churn happens. But, you lose out on transaction tracking over all employments of an individual.
2. Use the initials of first and last name and add a sequential number at the end. This gives you buckets of Ids, ideally 26P2 (Combinations). These buckets will not be evenly used.
Which rule is recommended to implement for user id generation when any identity is getting created in identityIQ. I have about 4 authoritative source and have implemented logic to generate user with firstname.lastname<Sequence Number> in creation rule. Logic works fine but when I re-run aggregation task (2nd time), it creates an another identity with identity attribute which is set in application definition. Any thought on this. What am I missing here.
Reusing an ID may present some audit and compliance challenges. For some organisations, it is recommended to always create a new ID to segregate the transactions done by each individual. The most recommended is always a new ID and mailbox for all new starters.
One challenge here is that IIQ doesn’t treat the Identity name as a name, but sometimes also as an ID. For example, the target of an AuditEvent is usually the name of the object.
This means that names need to be immutable.
Network IDs may not be immutable. Neither may employee IDs. (Consider a merger or new HR source for example.)
We typically just generate a GUID as the Identity name and then generate a username or other network ID in a separate field. The name is rarely shown to end users, and the display name can be set to whatever you want.
As far as uniqueness, truly guaranteeing uniqueness without race conditions means distributed locking. I prefer leaning on the DB for this. Create a plug-in table with one row, and then select that row FOR UPDATE (or whatever your DB uses) before generating an ID. When you commit the Connection, the row will be unlocked. Alternatively, create an atomic database procedure that does the locking and generation. The goal is to ensure that exactly one thread on one appserver generates an ID at any given time.
