Best Practices

for Managing
User Identiers
2014 Hitachi ID Systems, Inc. All rights reserved.
Contents
1 Introduction 1
2 Dening user identiers 1
3 Different types of identiers 1
4 Scope and uniqueness 2
5 When identiers are assigned 3
6 Machine-readable versus human-readable identiers 3
7 Desirable attributes of identiers 4
8 Addressing challenges in identier management 6
9 Common and recommended algorithms for assigning login IDs 7
9.1 Login IDs for internal users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.2 Login IDs for external users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3 Assigning new E-mail addresses to internal users . . . . . . . . . . . . . . . . . . . . . . . . 10
10 Example business processes 11
10.1 Employee / contractor onboarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2 Customer onboarding (Internet-facing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.3 Renaming an existing employee login ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
i
Best Practices for Managing User Identiers
1 Introduction
This document presents best practices for assigning and managing unique identiers to the users of com-
puter systems in medium to large organizations. It begins with denitions and background information, then
proceeds to explain scope, uniqueness, business processes, challenges and best practices.
2 Dening user identiers
What is a user identier, or ID for short?
Technical denition:
Multi-user computer systems often need to identify users, so that access to applications and data can be
controlled, logged and attributed to people. Computers refer to people using unique numbers or strings of
characters. These numbers or character strings are user identiers.
User-centric denition:
Users have a variety of identiers, which uniquely identify them in some context. Examples in the IT environ-
ment include operating system login IDs, e-mail addresses, employee numbers. Examples from day-to-day
life include drivers license numbers, credit card numbers and passport numbers.
3 Different types of identiers
In the context of a medium to large organization, users often have at least the following identiers:
1. An employee number.
2. At least one network login ID.
3. Possibly additional login IDs to a variety of applications.
4. At least one e-mail address.
This document offers guidance to organizations regarding the management of these corporate user IDs.
2014 Hitachi ID Systems, Inc.. All rights reserved. 1
Best Practices for Managing User Identiers
4 Scope and uniqueness
An ID must uniquely identify a person within a dened scope.
For example, since no two users can have the same login ID on an application, the application can be
thought of as an identication domain, within which each user has a unique ID.
Unique IDs commonly have a scope drawn from the following list of possibilities:
Scope Examples
Single system or application Active Directory domain, RAC/F security database.
Single organization Employee number, standardized cross-application login ID
Sub-national Drivers license, voter number.
National Passport number, federal tax number.
Global Fully qualied e-mail address.
In general, the scope over which an ID is unique can be expanded by appending the context where it was
dened. This can be illustrated with some additional examples:
Original scope Example Append New scope Example
Single system JSMITH Application
name
Organization JSMITH@App01
Single
organization
JSMITH Organization
name
Global JSMITH@Acme.com
State/province DL 1341135-013 Jurisdiction National DL 1341135-013@NewYork
National QC0318876 Country code Global QC0318876 from Canada
2014 Hitachi ID Systems, Inc.. All rights reserved. 2
Best Practices for Managing User Identiers
5 When identiers are assigned
When discussing how identiers are assigned, it is helpful to consider when they are assigned. Here are
some examples:
1. At birth as happens in some jurisdictions for government IDs, social insurance numbers, etc.
2. When joining an organization enrolling as a student, starting a new job, etc.
3. When being granted a new login ID to a system or application.
Identiers are sometimes changed as well for example following name changes, which in turn often follow
marriage or divorce.
6 Machine-readable versus human-readable identiers
People nd it easier to remember and enter memorable strings of characters. On the other hand, computers
are able to assign numeric identiers which are guaranteed to be unique in some scope. This leads to two
broad categories of identiers:
1. Human-friendly identiers, such as e-mail addresses and login IDs.
2. Computer-friendly identiers, such as globally unique IDs (GUIDs) - which are strings of 32 hexadec-
imal digits.
Computer-friendly identiers often have the benets of being unique in a larger scope and of never changing
during the lifecycle of a user. In contrast, user-friendly identiers are less unique (unique only in a smaller
scope) and more volatile, but are easier for people to manage.
2014 Hitachi ID Systems, Inc.. All rights reserved. 3
Best Practices for Managing User Identiers
7 Desirable attributes of identiers
Following is a list of desirable characteristics of user IDs. When designing an algorithm to assign IDs to
users or business processes for managing user IDs, it is helpful to consider each of these and to develop a
process which satises as many of them as possible.
Identify a person, not a position:
Identiers should refer to people, not to positions. People often move from one position to another and
changing their identier when this happens is a nuisance and creates inconsistencies in audit logs.
User friendly:
Identiers should be reasonably easy to remember and short enough to enter quickly. Long and
hard-to-remember IDs should be avoided unless they are only used by machines.
Easily recognizable:
It is helpful for users to be able to recognize that a string of characters is a user IDon casual inspection.
In other words, user IDs should be constructed in an easily recognizable format. This is helpful both
for users, when reading text that contains IDs, and for automated processes, which can scan log les,
scripts, network trafc or other data sets for user IDs.
Reusable:
It makes sense to assign the smallest possible number of identiers to a user and to reuse existing
identiers where possible. This is more user friendly, less troublesome to manage and easier to audit.
In short, use an existing identier if possible, rather than creating a new one. Standardized identiers
across as many systems as possible.
Compatible:
Identiers are often used on a variety of systems. For example, a user might type the same identier
to sign into Windows / Active Directory, into a mainframe using RAC/F and into an ERP running SAP.
Each of these systems will have different constraints on the allowable length and characters that
can comprise an identier. In order to support reuse (previous objective), it makes sense to assign
identiers that are compatible with the largest possible number of systems.
Maximum scope:
Different systems may have different, overlapping user populations. It makes sense to assign iden-
tiers which are unique over the largest possible scope, so that they can be reused by the largest
possible number of systems.
Unchanging:
Identiers assigned to a user should be designed so that they never have to be changed. Changing
identiers is an administrative burden and leads to inconsistencies in audit logs,
Changes in user IDs can create signicant operational problems. For example, the ID may appear on
multiple systems, making it costly to change. Changing the ID would create a discontinuity in audit
logs, perhaps violating security policy. The ID may be embedded in programs or scripts, which would
stop working after the change. The ID may be known to other users, who would have to be informed
of the change.
2014 Hitachi ID Systems, Inc.. All rights reserved. 4
Best Practices for Managing User Identiers
Never reused:
Identiers should never be reused. For example, when a user leaves an organization, that (old) users
identier should never be assigned again, to another (new) user. Doing so can have undesirable
and unexpected consequences, such as the new user acquiring security access rights from the old
users prole. This means that a repository of every identier that has ever been assigned must be
maintained, rather than just a repository of currently-in-use identiers.
Not offensive:
People have an amazing ability to read meaning into meaningless strings of characters. This leads
to situations which range from humorous to offensive, where identiers are assigned to users, often
by automatic processes, which users can read literally or with poetic license to have colorful or
offensive meanings.
This problem suggests that a human review process is often needed when new identiers are as-
signed, so that they can be vetted and perhaps replaced if they are found to be offensive.
Cross-language:
Many organizations span countries, languages and cultures. In this context, a question of cultural,
rather than just technical compatibility arises. For example, would a uniligual English speaker be able
to read, remember or type an identier for a co-worker if that identier is in Kanji (Japanese)?
Since identiers may have to be accessible by multiple users, it is important to consider the ability of
users uent in different languages to read and enter them.
Accessible only within an appropriate scope:
In some cases, an organization may consider identiers to be condential. This is true in the legal
sense with some identiers, such as social security numbers. Condentiality of identiers may also
be considered a secondary line of defense against security attacks such as automated password
guessing.
Since users often have to know, remember and enter their own identiers, condentiality means limit-
ing the visibility of identiers to just authorized users and not disclosing information about whether an
identier is valid to unauthorized or unauthenticated users.
2014 Hitachi ID Systems, Inc.. All rights reserved. 5
Best Practices for Managing User Identiers
8 Addressing challenges in identier management
Some challenges arise in most organizations in the course of assigning new or managing existing identiers.
These are described below:
Collisions:
If the algorithm used to assign unique IDs to users is based on users names then users with identical
or even similar names may be assigned the same identier. This obviously needs to be rectied.
For example, an organization may employ 10 people with the (common among English speakers)
name Michael Smith. If IDs are assigned using the algorithm last name plus rst initial then they
would all be assigned the ID smithm. Assigning the same ID to multiple users would defeat the
purpose of IDs unique identication so the algorithm must be adjusted to eliminate these collisions.
This may be done by appending one or two digits to the IDs above, for example.
Name changes:
Where IDs are assigned using an algorithm based on the users name, in the event that the users
name changes (for example, due to marriage or divorce) the user may wish the in the event that the
users name changes (for example, due to marriage or divorce) the user may wish to change his ID to
match his new name.
Changes to user IDs are undesirable, as described in Section 7 on Page 4.
Short names:
Where IDs are based on user names, the algorithm used to calculate IDs may produce unsatisfactory
results for users with short names. For example, two common Chinese surnames are written (in
English) as Wu and Li. An organization with many Chinese users and IDs based on surname might
have many collisions and require two or more extra characters appended to IDs, to make them unique.
These unique sufxes are hard to remember and tend to lead to confusion, such as e-mails intended
for one user being sent to another.
Changes in user role or status:
Where IDs are based on a users role (e.g., which department he works in) or status (e.g., employee
vs. contractor), changes in the users role or status would trigger a change to the users ID. For
example, a contractor who is subsequently hired as an employee would be assigned a new ID.
Changes to user IDs are undesirable, as described in Section 7 on Page 4.
Multiple character sets:
As described in Section 7 on Page 5, users uent in one language, or whose computer is congured
for text input in one language, may be unable to read, remember or enter an ID in another language,
especially when the two languages use different character sets.
2014 Hitachi ID Systems, Inc.. All rights reserved. 6
Best Practices for Managing User Identiers
9 Common and recommended algorithms for assigning login IDs
9.1 Login IDs for internal users
The following process and algorithm can be used to satisfy each of the requirements set forth in Section 7
on Page 4:
Requirement Strategy
Identify a person Assign IDs to people, not roles.
User friendly IDs should be 7 characters, total.
Easily recognizable Formulate IDs as Unnnnnn where n represents a digit. There are
10,000,000 possible IDs of this form.
Reusable Use the same ID on every system and application.
Compatible IDs starting with a letter and containing only one letter and 6 digits
work on almost every conceivable system and application.
Maximum scope Assign an ID to every user in the organization and use these IDs to
sign users into applications. If possible, use the same ID as an
employee number as well.
Unchanging Since the IDs are numeric, changes in user names should not trigger a
request for a new ID. Since they do not represent user role or status,
changes in these attributes also do not trigger a request for a different
ID.
Never reused Create a database of every ID ever assigned. Only append to it and
never reuse IDs.
Not offensive Numbers are not generally offensive, though some numbers are
considered bad luck in some cultures. Give users an opportunity to
request a new ID (but not to specify what it will be) when they are rst
assigned an ID.
Cross-language Roman letters (U) and digits are legible across cultures and languages.
Limited disclosure Do not publish lists of IDs or the correlation between user names and
IDs.
2014 Hitachi ID Systems, Inc.. All rights reserved. 7
Best Practices for Managing User Identiers
Another reasonable process is as follows:
Requirement Strategy
Identify a person Assign IDs to people, not roles.
User friendly IDs should be 7 characters, total.
Easily recognizable Formulate IDs as the users surname, in English, with up to 3
characters followed by a 4 digit number assigned sequentially for each
prex. Example: the fourth Mike Smith could be assigned SMI0003.
Reusable Use the same ID on every system and application.
Compatible IDs always start with a letter, only have letters and digits and contain
no more than 7 characters. Almost every conceivable system and
application supports this.
Maximum scope Assign an ID to every user in the organization and use these IDs to
sign users into applications. If possible, use the same ID as an
employee number as well.
Unchanging Since IDs do not represent user role or status, changes in these
attributes do not trigger a request for a different ID. Changes in a
users name may cause users to request an ID, but in most cases only
a short subset of the name is used, so users are likely to tolerate
continuing use of their old ID.
Never reused Create a database of every ID ever assigned. Only append to it and
never reuse IDs.
Not offensive Short strings of letters are not usually offensive and neither are
numbers. Give users an opportunity to request a new ID, indicating the
string they did not like, when they are rst assigned an ID.
Cross-language Roman letters and digits are legible across cultures and languages.
Limited disclosure Do not publish lists of IDs or the correlation between user names and
IDs.
2014 Hitachi ID Systems, Inc.. All rights reserved. 8
Best Practices for Managing User Identiers
9.2 Login IDs for external users
External users that sign into an organizations Internet-facing applications generally only sign on infre-
quently. Since Internet users generally already have an e-mail address and since e-mail addresses are
guaranteed to be globally unique, it makes sense to identify external users with their fully qualied e-mail
address.
This has many advantages:
Requirement Strategy
Identify a person Use fully qualied e-mail addresses.
User friendly Users already know their own e-mail addresses.
Easily recognizable E-mail addresses are easily recognized by people and programs.
Reusable Users already use their e-mail address elsewhere, so by denition
assigning this as an ID is reusing it.
Compatible E-mail addresses are not compatible with all applications. They can be
quite long (over 100 characters) and may contain symbols not
supported by some applications (@, _, -, .). These limitations are not
usually problematic with Internet-facing applications, but they can
present difculties for back ofce systems, such as mainframes.
Maximum scope E-mail addresses can be used as IDs on every Internet-facing
application.
Unchanging Users do periodically change their e-mail address, so this requirement
is, unfortunately, violated.
Never reused Few if any e-mail systems assign the same ID, consecutively, to
different users. This reduces the problem of ID reuse to a vanishingly
small size.
Not offensive Users presumably already address this problem when provisioning
their e-mail account, so this problem is transferred to another
organization.
Cross-language SMTP e-mail addresses are, by denition, cross-cultural and global.
Limited disclosure E-mail addresses are widely known, so this requirement cannot be
met using this strategy.
2014 Hitachi ID Systems, Inc.. All rights reserved. 9
Best Practices for Managing User Identiers
9.3 Assigning new E-mail addresses to internal users
Requirement Strategy
Identify a person Assign a new and unique e-mail address to every new e-mail user.
User friendly Assign rstName.lastName@organizationDomain and insert .uniqueID
before the @ if required, where the uniqueID is two letters aa, ab, ac,
etc.
Easily recognizable E-mail addresses are easily recognized by people and programs.
Reusable Users can use their e-mail address to sign into a variety of web-based
applications. Since many legacy applications do not support long IDs
or IDs containing punctuation marks, e-mail addresses cannot be
reused everywhere, nor should they because they are long and so
take longer to type than other, typically internal IDs.
Compatible E-mail addresses a standard format, compatible with all mail systems.
Compatibility with other applications is not predictable.
Maximum scope E-mail addresses can be used as IDs on many 3rd party
Internet-facing application.
Unchanging Unfortunately, users will generally demand changes to their e-mail
address when their name changes. This is unavoidable with this
format.
Never reused Create a repository of all current and previously assigned e-mail
addresses. Even in the case where a user with a given name leaves
and later a different person with the same name joins, use the unique
eld.
Not offensive Users are not generally offended by their own names.
Cross-language SMTP e-mail addresses are, by denition, cross-cultural and global.
Limited disclosure E-mail addresses are widely known, so this requirement cannot be
met.
2014 Hitachi ID Systems, Inc.. All rights reserved. 10
Best Practices for Managing User Identiers
10 Example business processes
Following are some typical examples that illustrate how the naming algorithms described in Section 9 on
Page 7 above are used.
10.1 Employee / contractor onboarding
1. For employees: HR creates a new employee record.
2. For contractors: a manager submits a new-contractor request.
3. In either case, the request includes the users full name.
4. Once the request is approved:
(a) A new login ID is assigned.
(b) Using the algorithm in Subsection 9.1 on Page 7:
i. A database is referenced to nd the highest-number, already-assigned ID.
ii. The next number is used.
iii. Database locking is used to ensure that two users, provisioned at nearly the same instant,
do not get the same ID.
iv. The ID might be U0012311..
(c) A new e-mail address is assigned.
(d) Using the algorithm in Subsection 9.3 on Page 10:
i. John Smith might become john.smith@acme.com
ii. As with the previous example, a database lookup is required to check for duplicates.
iii. If a duplicate is found, the e-mail address might become john.smith.aa@acme.com
iv. The new ID must be stored in the database, correlated to U0012311.
v. Also as before, record locking semantics must be used to avoid a case where two same-
named users are assigned the same address if they are provisioned nearly simultaneously.
10.2 Customer onboarding (Internet-facing)
1. A new customer lls in an access request form.
2. The form should include a CAPTCHA to ensure that it is lled in by a person, rather than a (possibly
malicious) script.
3. The user should be required to enter his existing e-mail address.
4. Form input should validate that the e-mail address is well formed.
5. Account activation may involve e-mail validation:
(a) An activation URL is sent to the users e-mail address.
(b) The URL includes a pseudo-random string.
(c) The user has to click through to the URL to activate the account.
2014 Hitachi ID Systems, Inc.. All rights reserved. 11
Best Practices for Managing User Identiers
(d) Activation strings and un-activated accounts should be scrubbed periodically for example when
they are over 24 hours old.
6. This method ensures that all users have a globally-unique, already-remembered ID.
7. Password reset can be accomplished by sending an activation string to the user, just like account
activation.
10.3 Renaming an existing employee login ID
1. Users may ask for a new ID in the event that their old ID was based on their name, which has since
changed.
2. Organizational changes mergers, acquisitions, etc. may trigger renames to align naming stan-
dards.
3. In general, so long as a user has the same ID on all systems, it is safer to leave that ID alone and
provision any new accounts for the same user with the pre-existing ID. Name changes are dangerous
since scripts or programs may explicitly refer to the old name.
4. Where renaming a user is deemed essential, be careful to consider:
(a) Scripts or programs that refer to the old ID.
(b) Uniqueness of the new ID (should not be used by any other user on any system).
(c) Compatibility of the new ID with all systems, not just those which the user will access immediately.
5. Before renaming a user, notify him of the change, both so that he can sign in after it happens and so
that he can report problems that may have been caused by the change quickly.
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/assigning-ids/managing-user-ids-1.tex
Date: 2011-02-11