Introduction to Identity Management: Self-Service

Identity Management (IdM) is a term that defines a collection of processes and activities surrounding the management of records about identities for the purpose of controlling access (authentication) and privileges (authorization) within or across multiple computer systems.  Self-Service is a subset of features within Identity Management that defines activities a user can do with a computer system on their own, without reaching out to helpdesk or IT personnel. Here are seven common Self-Service features, their typical use cases, and some some concepts that are important when implementing Self-Service features in an IdM solution.

Self-Service Features

1. Change Password

At any time, a user should be able to change their password on their own account without assistance from the helpdesk and without anyone knowing. The process goes something like this:  The user must authenticate to the IdM system before changing their password. Once authenticated, a screen is presented to the user that asks for three things:

• Old Password
• New Password
• Confirm New Password

The old password is required to prevent a malicious user from gaining access to a computer that has already authenticated to the IdM system and changing the password without the account holder’s knowledge. The new password is verified by requiring it to be entered twice. Because passwords are typically masked on the screen, requiring double entry minimizes the occurrences of typos.

Alternate flows with this feature can include forcing the user to log off and immediately log in again using their new password. Some IdM systems will email a one-time token or link to the email address on record in the account.

2. Forgot Password

I’m sure this has happened to you before. Be careful when implementing self-service features that provide a service to users who are not authenticated. If a user does not know their password, they cannot prove their identity using the typical authentication mechanism of entering credentials. So in this case, another authentication method is required.

The user is prompted for their username or another unique piece of identifying information.  Many IdM systems use email address as the unique identifier. Because the user is not authenticated, the IdM system needs to verify their identity using another method, which tries to answer the question, “Are you really who you claim to be?”

Typically, you’ll see security questions. These are questions that the user selected and provided answers to when they originally set up their account. If users answer correctly, they are allowed to immediately change their password and are dropped into the process flow of self-service feature #1, except they do not have to enter their old password, since they don’t know it.  If the user cannot successfully answer their security questions; that is, they are prevented from proceeding and must call the help desk.

3. Modify Account Profile.

This feature allows a user to change information in their account profile. Typically personal information is collected and recorded to allow identification of the person setting up an identity record. Some of that information can change over time and users need a way to keep their information up to date.  For example, a last name will change when a person get married or an email might change if a user changes Internet service providers.

The user must authenticate to the IdM system before being allowed to change their profile information.  After login, a screen is presented to the user that shows their profile information and allows them to modify attributes on their record and save those changes to their record.  In some cases the user will be disallowed from changing a particular field, like the username. Other times, certain attributes might require the user to follow a more complex process to modify the data.  For example, if the user wants to change their email address they may be required to verify the new email address before being allows to change it.

4. Forgot Username

Sometimes users access a system so infrequently that they forget the unique ID, typically username, they established when they originally registered. When this happens, IdM systems provide a mechanism to recover the username.

This self-service feature is more complex than previous features defined. The main reason for this relates directly to security.  During a normal credential based authentication, the username provides information to the IdM system about who is attempting access and the password provides verification that the user is who they say they are.  However, when a user does not remember their unique ID, the IdM system must first answer the question, “Who are you?”

When implementing a ‘forgot username’ feature, care must be taken to prevent any information from being “leaked” to a malicious user. IdM systems can’t simply show a list of names with address and ask the user to select their record. This would reveal way too much information about the users managed in the system.

The IdM system prompts the user for multiple pieces of information that are used to search the identity record database for a match. Some combination of attributes maintained by the IdM system are used for this purpose. First name, last name, date of birth, and any other attributes that don’t or rarely change can be used. Once the user provides the required information, an exact search is made. Users must be prompted with enough attributes to guarantee a match against a single record. If a match cannot be found or more than a single record is returned from the search, the user is not allowed to recover their username and is forced to call the help desk.

If a match is made against a single record, the user must then prove they are the account holder of the record found.  Most likely, if the user could not remember their username, they also do not remember their password.  Again, the IdM system is trying to answer the question, “Are you really who you claim to be?”  At this point, the user can be dropped into the process flow of self-service feature #2, Forgot Password.

5. Registration

Registration is the process by which a user sets up or established an identity account for the very first time.  It is a simple process, but because the IdM system is establishing trust with a user for the first time, there are some important factors to consider.

There is an implicit level of trust that exists when the registration process starts. That is, the IdM system affirms that the person creating a new account is providing information about themselves and is the person that will later be allowed to access that account. A series of questions is presented to the user to gather data about the user in three areas:

1. Personal, Unique, and Static Information
2. Security Related Information
3. Business Specific Information

The information acquired, along with the acknowledged trust allows an identity record and account to be created. The IdM system also needs to gather information in order to provide its defined security service.  For example, it must prompt for things like a password and answers to security questions so the account can function in the IdM system.

In addition, most IdM systems will gather information from users that relates to the type of business that is using the IdM system.  These are items that are specific to a line of business or specific to a particular organization.  Many times this information is key to authorizing this account to see data records or perform activities.

The purpose of gathering all this information is two-fold.  First, it allows the IdM system to prevent duplicate identity records from being created for the same person.  Most IdM systems operate with a mantra of, “One user; one identity.”  Enforcing a single identity record for a single person reduces fraud and allows the maintenance of separation-of-duty policies.  Uniquely identifying people and records is crucial to this effort. Second, the information gathered is used to vet the person and account being created.  Many times the data gathered is compared to other internal system data to verify identity or approve some level of access to data and functionality.

After uniqueness has been established and the registrant’s information has been vetted, a new identity record is created that allows to user to log in to the system.

6. Request Access and Privileges

This feature allows a user to request access or additional privileges to a specific application or system that is protected.

After login, the user navigates to a screen that shows a list of additional components (systems and features) where the user is permitted to request access. This list of options is sometimes based on information already known about the user making the request; community, existing access, etc.

The request lands in a queue for approval which notifies an authority over the requested system. See feature #7 – Manage Requests to see how this process continues. For the user, the request process is complete. Alternately, some requests for access can be configured to auto-approve. In this case, the user would not have to wait for access, but could begin using the system or feature immediately.

7. Manage Requests

This feature can sometimes be considered an administrative function. Business users within an identity system typically control access to specific areas (applications, systems, features, etc.).  When an end user makes a request to gain access to an area, the business user needs a mechanism to approve or deny it.

Once they are logged in, the admin navigates to a screen that displays all of the unanswered requests for access for their specific area of authority.  They can either deny or grant approval on each request.