Identity Management Terminology

Abstract

Identity management is becoming an important technology for managing users, accounts, passwords, provisioning processes and deactivation processes for enterprise-scale organizations.

Since identity management is relatively new, the language used to describe it is not well defined or consistent.

This document attempts to clarify what terminology relevant to identity management means, to help the reader focus on solving real problems, rather than understanding apparently vague or conflicting product descriptions from peers, vendors or analysts.

Introduction

Identity management is becoming an important technology for managing users, accounts, passwords, provisioning processes and deactivation processes for enterprise-scale organizations.

Since identity management is relatively new, the language used to describe it is not well defined or consistent.

The identity management landscape

Identity management is a shared platform and consistent processes for managing information about users: who they are, how they are authenticated, and what they can access.

The following sections define key concepts that underly all identity management processes and technology.

Managed system

A managed system may be an operating system, database or application where users access some features or data, and where user access must be controlled.

Platform

A type of managed system. There are many possible types of platforms, including:

Network operating systems: Windows NT, Windows 2000, Novell NetWare, etc.
Directories: LDAP, x.500, etc.
Host operating systems: MVS/OS390/zOS, OS400, OpenVMS, Tandem, Unisys, etc.
Groupware and e-mail systems: MS Exchange, Lotus Notes, Novell GroupWise, etc.
Applications: SAP R/3, PeopleSoft, Oracle Applications, etc.
Database servers: Oracle, Sybase, MSSQL, Informix, DB2/UDB, etc.

An identity management system may manage access and authentication to systems of various types.

User

Users are people whose access to systems and identity information must be managed.

Help desk analyst

A help desk analyst is a user with special privileges, that allow him to assist other users, for example by resetting their forgotten passwords.

System administrator

A system administrator is a user with absolute control over a managed system. The system administrator may install any or all software on the managed system, can create or delete other users on that system, etc.

Resource

Resources are data or functions that users access on systems.

More broadly, resources may also include physical objects or capabilities, such as building access cards, furniture, computers, telephones, tokens, etc.

Account

An account is the collection of data used by a system to identify a single user, authenticate a user and control that user's access to resources.

User ID

(1) On most systems, accounts are uniquely identified by a short string of characters. This is called the User ID, login ID or login name.

Standard user ID

In some environments a user may have a standard user ID, which is expected to be the same on every system.

Global user ID

A global user ID is an identifier which uniquely identifies a user in an organization. It may or may not be used as the User ID on any one system, but is guaranteed to be unique (i.e., no two users may share the same Global user ID).

Alias

A user is said to have an alias on a particular system in case there is some notion of a global or standard user ID, but on the system in question the user signs on with a non-standard ID. The alias is that non-standard ID.

An alias may also be referred to as an alternate user ID, or a non-standard user ID.

Orphan account

(2) An orphan account is an account belonging to a user who has left the organization.

Directories

(3) A directory is the collection of accounts managed by a single system. Directories may be internal to a system (e.g., the SAM database in a Windows NT domain), or may be shared by multiple systems (e.g., an LDAP directory).

Privileges

A privilege is the right to do something on a system. Privileges normally relate either to the ability to access data (e.g., update a payroll record) , or the ability to use some feature (e.g., surf the Internet).

User groups

A user group is a list of accounts on a system. User groups are used to simplify administration of privileges (i.e., assign privileges to the group, and actively manage just the membership of the group). User groups are also used for non-security functions, such as mailing lists.

Access

A user's access to a system consists of the user's account, membership in groups, and privileges assigned either directly to the user or to the user's groups.

Authentication

Authentication is a process used by a system to uniquely identify a user. Most systems authenticate users by asking them to type a secret passwords. Other forms of authentication include:

Using hardware tokens.
Using a PKI certificate.
Using a smart card.
Providing a biometric sample (finger print, voice print, etc.)
Answering personal questions.

Authenticator

The data used by a user to sign into a system. May be a password, answers to personal questions, a smart card, a hardware token, etc.

Authentication typically consists of one or more "factors:"

Something the user knows (e.g., a password or answers to personal questions).
Something the user has (e.g., a hardware token).
Something the user is (e.g., a finger print, voice print, etc.)

Credentials

A user's credentials to a system consist of a unique user ID and an authenticator. In most cases, the authenticator is a password.

Single sign-on

Most systems require users to identify themselves and authenticate before they gain access. Single sign-on systems attempt to capture identification and authentication information once, and provide it to systems accessed by a user automatically. The objective of single sign-on systems is to reduce the number of different authenticators a user must have/know, and to reduce the frequency with which the user must provide those authenticators to systems.

Central user administration

All systems that incorporate access control define at least one class of user that can create new users and manage their access and authentication data. Such users have the right to perform central user administration (i.e., they have administrative power over all other users).

Delegated user administration

(4) As the number of accounts in a system grows, central user administration becomes impractical. Delegated user administration is a feature found in some systems to enable designated users to create new users and manage existing users in just a segment of the user directory.

Access change authorization workflow

(5) Administrative changes to the user directory may require authorization from appropriate people in the organization.

An access change authorization workflow system is used to:

Identify the people whose authorization is required to make a change
Ask those authorizers to approve a change request
Accept feedback from those authorizers and
Either trigger an automated action or report on the results of the authorization process.

Different people may be engaged in an access change authorization workflow process.

Requester

A requester is a person who submits an access change request. The change may be to alter the requester's own access to systems, or to alter another user's access privileges.

Request router

A request router is a person who may be called on by the workflow system to decide whose authority is required to approve a request.

Authorizer

An authorizer is a person whose approval is required before a request can be acted on. Authorizers normally fall into two categories: those selected based on the identity of the requester or recipient (e.g., someone in the management hierarchy), or those selected based on the resources requested (e.g., business owners of applications or data).

Security administrator

A security administrator is a person who manually administers user access rights to systems. A workflow system may call on a security administrator to fulfill an approved request on systems where automated administration agents are not available or have not yet been configured.

Recipient

The recipient is the person whose access privileges will change once an access change request has been approved and fulfilled.

User ID reconciliation

(6) Users may have different User IDs on different systems. Any system intended to manage user access or authentication across multiple systems must begin by constructing profiles for each user, which attach User IDs on each system where that user has an account to that user.

The process of constructing these User ID profiles is called User ID reconciliation.

Public Key Infrastructure

A public key infrastructure (PKI) is a set of systems for managing paired public and private keys, which principals (including users and systems) can use to authenticate to each-other, to sign documents and to send private messages to each-other.

Principal

A principal is a user or system that participates in the PKI.

Symmetric encryption

Symmetric encryption is a method for transforming text or data, using a key, into a form that is inaccessible to anyone who does not have that key. Encryption is symmetric where the key used to encode the data is the same as the key used to decode it.

Asymmetric encryption

Asymmetric encryption is a method for transforming text or data, using a pair of keys. Data encrypted by one key can only be decrypted by the other key.

Encryption key

An encryption key is a sequence of numbers used to encrypt or decrypt data.

Private key

A private key is one of a pair of keys used for asymmetric encryption. The private key is intended to be closely controlled by a principal -- not shared with anyone else.

Public key

A public key is one of a pair of keys used for asymmetric encryption. It matches a principal's private key, and is intended to be widely and publically distributed.

Message digest

A digest is a large number calculated from the contents of a document. The digest and the document form a pair -- it is very difficult to change one without invalidating the other.

Signature

A principal can sign a document either by encrypting it with his private key, or calculating a digest of the document and encrypting that with his private key.

Private transmission

A document can be transmitted by one principal to another in private, so that only the intended recipient can read it, and so that if another principal intercepts the transmission, the intercepted data will be useless.

Private transmissions are implemented in a PKI by encrypting the message with the intended recipient's public key.

Cryptographic authentication

A PKI allows principals to authenticate one another using asymmetric encryption. A client (C) claiming to be a principal (P) authenticates to a server (S) as follows:

S sends C a random number R.
C encrypts R with his private key, and sends the result to S.
S decrypts the result with P's public key.
If the result matches R, then S knows that C must possess P's private key, and so C is assumed to be P.

Certificate

A principal may verify the authenticity of a public key that purportedly belongs to another principal by checking that it is signed by a trusted third principal (a certificate authority). A public key signed in this way is called a certificate.

Certificate authority

A certificate authority is a principal in a PKI trusted by by many other principals to sign each-others' public keys.

Key distribution

A PKI relies on principals knowing each-other's public keys.

Key distribution is a process for ensuring that the principals have copies of the public keys they require, and that these copies are valid.

Centrally managed PKI keys

Principals in a networked PKI may store their private keys on a secure central service. This allows principals to move around a network and access their own keys as required.

Physically distributed PKI keys

Principals in a networked PKI may store their private keys on their own workstations or even on removable media (floppy disks, CD-Rs, etc.)

This tends to improve security at the expense of mobility and ease of administration.

Defining access management

(7)

An access management system streamlines the processes of creating, updating and deactivating accounts.

The following sections define key concepts that underly all access management systems.

Provisioning

The process of setting up accounts and possibly other resources, such as furniture, computer equipment, telephones, etc. for users. Provisioning is usually triggered by hiring a new user or moving an existing user to a new location or job.

e-Provisioning

e-Provisioning means provisioning strictly electronic access (i.e., accounts, but not physical objects).

Deactivation

(8) Deactivation is the process of disabling a user's accounts, so that the user can no longer authenticate to those systems or access their resources or functions.

Deactivation does not necessarily imply that the accounts are deleted -- simply that they are made inoperative.

Termination

Termination of a worker typically results in the deactivation of that person's access. Please see (8).

Account update

User accounts may periodically need to be updated, to refresh password values, change the user's name, update group membership or change privileges. Account update is any process that accomplishes one or more of these tasks.

Delegated user administration

Please see (_label_delegated-admin).

Role-based access control

In the context of a single system, role-based access control (RBAC) means a process where access privileges on a single system are grouped into roles, and users are attached to roles as a convenient mechanism to manage their privileges.

Implementation of single-system RBAC is simple, and almost every modern operating system and database supports roles or privilege groups.

In the context of a access management across multiple systems, role-based access control (RBAC) means that types of accounts on multiple systems are grouped into roles, and users are attached to roles as a convenient mechanism to control user privileges across multiple systems.

Implementation of multi-system RBAC is complex, since users may belong to multiple roles, which specify different or conflicting privileges on the same system. User classification, role definition and conflict resolution make multi-system RBAC a significant challenge.

Rules-based access control

(9) Rules-based access control is a strategy for managing user access to one or more systems, where business changes trigger the application of rules, which specify access changes.

For example, when a user is hired (business change), he may automatically get some default system access, such as network and e-mail accounts. Alternately, when a user is terminated, business rules may specify that all of his accounts should be disabled.

Implementation of rules-based access control systems is feasible so long as the number of triggering business events and the set of possible actions that follow those events are both small.

Policy-based access control

Policy-based access control is a strategy for managing user access to one or more systems, where business classification of users is combined with policies to determine what access privileges a user should have. Theoretical privileges are compared to actual privileges, and differences are automatically applied to managed systems.

For example, a role may be defined for a territory sales manager. Specific types of accounts on the network, sales-force automation software and document management system may be attached to this role. Appropriate users are then attached to this role. A policy-based provisioning system would evaluate the actual privileges of every territory sales manager, and automatically create these types of accounts for users who did not already have them, and disable any accounts these users had on other systems.

Implementation of policy-based access control systems is challenging, because it requires a significant investment in new information:

An exhaustive set of roles must be defined.
The access requirements of every user must be fully specified in terms of roles.
A periodic process must be able to measure the privilege set that each user has, and compare it to privileges that the security policy defines.

Automated provisioning

Automated provisioning is another name for rules-based access control. Please see (_label_rules-admin).

Authorization

Changes to user access to systems are normally made to reflect business changes. Authorization to make changes is normally required before they are applied to systems.

Access change authorization workflow

Please see (5).

Directory migration

Mergers, divestitures and software changes periodically necessitate that large numbers of user accounts be moved from one system to another in a short period of time.

Access management systems may provide tools to assist in such migrations: to list and characterize users on one system, and to automatically create batches of users on another system.

Directory cleanup

Manual system administration over an extended period of time tends to leave orphan accounts (see (2)). Directory cleanup is a process used to identify orphans, and deactivate their accounts.

Some access management systems incorporate tools for directory cleanup, including identification of orphans based on last login time/date, or based on user ID reconciliation ((6)); and including batch deactivation of access.

Template account

Access management systems typically create new accounts using templates. Templates simplify the specification how a new account should be configured.

A template may be a model account, created on the managed system, or a set of attributes that describe a type of user, defined inside the access management system itself.

Model account

A model account is an account created on a managed system specifically as a definition of how a particular type of account should be created in the future. Model accounts represent classes of users, and are not normally used by a real user.

Resource disposition

On most systems, accounts may "own" data objects, such as files, data sets, table spaces or mail folders.

When accounts are deleted, something must be done with the objects they own. Options include deleting the owned objects, changing their ownership so that they belong to another user, or moving them to a common location. The process used to dispose of objects owned by deleted accounts is called resource disposition.

Defining authentication management

(10)

An authentication management system streamlines the processes of updating passwords and managing other types of authenticators.

The following sections define key concepts that underly all authentication management systems.

Password

A password is a secret string of characters that a user types when signing into a system, to prove his identity.

Identity is established by virtue of the assumption that no other person knows the user's password. This implies that the password is difficult to guess, is not written down, and has not been shared with others.

Password policy

A password policy defines what constitutes an acceptable password, and how passwords should be managed.

It consists of password composition rules, such as minimum length, use of dictionary words, mixed letters and digits, etc. It also includes policies about how and when to change passwords and whether passwords may be written down or shared.

Representational limits

In the context of a password policy, representational limits represent what a given system can physically represent in a password field. Examples include a maximum length or a list of valid characters.

Complexity requirements

In the context of a password policy, complexity requirements are rules used to prevent users from selecting trivial, easily guessed passwords. Examples include disallowing use of the user's login ID or name, minimum password length, dictionary checks, limits on repeating characters, requirements for mixed case or digits, etc.

Password synchronization

A password synchronization system is any software or process used to help users maintain a single password value on multiple password-protected systems.

Password synchronization may be optional or mandatory. Users may be encouraged to synchronize their passwords manually, or provided with an automated system for updating multiple passwords simultaneously.

Transparent password synchronization

A transparent password synchronization system is one which intercepts password changes as they take place on an existing system (typically a network operating system or directory), and automatically propagates the new password to other systems.

Blocking record

A blocking record is data communicated from one password synchronization server (A) to every transparent password synchronization server (B, C, ...) on a network.

The blocking record indicates that (A) is actively engaged in synchronizing passwords for a given user (U), and that transparent password synchronization servers (B, C, ...) should ignore any events that would otherwise trigger transparent password synchronization for that user (U).

Web-based password synchronization

A web-based password synchronization system is one where users access a new user interface, normally through a web browser, to update multiple passwords at once, and hence synchronize them.

Users are intended to use the new user interface instead of the existing "native" password update facilities on the systems where they have login accounts.

Password change

A password change is a routine process whereby a user, who knows his own password, selects a new, replacement password value for use on one or more systems.

Intruder lockout

Some systems monitor failed authentication attempts, and if too many attempts to sign on with a single account are detected, the account is locked.

This mechanism is intended to deter intruders, who may attempt to guess the password for one or more accounts.

Intruder lockout may also be triggered by users who persistently mistype their own passwords (e.g., with the Caps Lock or Num Lock key depressed).

Intruder lockouts mean that authentication to the affected account is impossible, but the account has not been intentionally disabled by an administrator.

Most systems differentiate between locked and disabled accounts.

Disabled account

An account is disabled in the event that some administrator or access management process, presumably with suitable authorization, actively set a flag to prevent further logins to that account.

Most systems differentiate between locked and disabled accounts.

Password reset

(11) A password reset is some process where a user who has either forgotten his own password, or triggered an intruder lockout on his own account, can authenticate with something other than his password, and have a new password administratively set on his account.

Password resets may be performed by a help desk, or by self-service automation.

Self-service

Self-service is any process that allows a user to access a system function that would otherwise only be available to a system administrator or help desk analyst.

Self-service password reset

(12) A self-service password reset is a password reset ((11)) accomplished by interaction between the user and automated software (a web site, IVR system or other facility).

Self-service password resets are similar to assisted password resets ([link]), but without intervention of a support analyst.

Assisted password reset

(13) An assisted password reset is a password reset ((11)) accomplished by interaction between the user and a support analyst, typically over a telephone.

Assisted password resets are similar to self-service password resets ((_label_self-service-reset)), but with the intervention of a support analyst.

Q&A authentication

Users who require a self-service password reset must authenticate with some non-password authenticator. The most common form of non-password authentication prompts a user to answer one or more personal questions. Authentication is premised on the assumption that only the user would know the answer to these questions.

Question set

Questions that a user must answer in order to authenticate may be grouped into sets. A question set may consist of either pre-defined (the same for every user) or user-defined (possibly different for every user) questions. Each user will have their own answers to each question in each set.

Question sets may have other attributes, such as:

Location and manner in which the personal data is stored.
Answer formatting.
Algorithm for comparing registered user information with what the user types to authenticate.
Number of questions.
Circumstances under which data from the question set is used for authentication.

Secure kiosk account

A secure kiosk account (SKA) is a specially constructed and locked down network operating system login account. It is typically used to allow users who forgot or otherwise disabled their network login password to gain access to a self-service password reset facility.

Some characteristics of an SKA include:

An easy-to-remember name, such as help.
A blank or trivial password.
A security policy which prevents access to most or all network resources and services.
A security policy which prevents access to most or all workstation resources and services.
A security policy which replaces the default workstation user interface shell with a program that provides access to just the self-service password reset facility.
Specialized software to further enforce the policies described above.

A SKA may be used for applications other than self-service password reset -- for example, in a retail or public setting, an SKA may be used to convert a PC into a public Internet or Intranet kiosk.

Client-side secure kiosk account

A client-side secure kiosk account is a SKA implemented as a user, security policy and supporting software installed locally on a workstation.

Client-side SKA may be deployed instead of a normal, network-implemented SKA for several reasons:

Compliance with security policy that forbids definition of "generic" network accounts with trivial or blank passwords.
Allowing disconnected or intermittently-connected users to access a local SKA, which automatically connects their workstation to the network before displaying a self-service user interface.
Supporting users whose workstations are simply not a part of a domain or other network login structure.

Hardware tokens

A hardware token is an authenticator in the form of a physical object, where the user's interaction with a login system proves that the user physically possesses the object. Proving possession of the token may involve one of several techniques:

Reading a periodically changing pseudo-random number from the token's display and typing it into a login prompt.
Keying a challenge string displayed by the login system into the token, and typing a string that the token displays as a result back into the login system.
Plugging the token into the workstation, using a USB port, or some other connection (parallel or serial port, smart card slot, etc.).

Hardware tokens authenticate users on the basis that only the token assigned to the user could have generated the pseudo-random number or code response keyed in by the user. Successful entry of this code implies that the user is in physical possession of the token. This implies that the user does not allow users to use his token, and has not lost it.

Biometric authentication

Biometric authentication is any process that validates the identity of a user who wishes to sign into a system by measuring some intrinsic characteristic of that user.

Biometric samples include finger prints, retina scans, face recognition, voice prints and even typing patterns.

Biometric authentication depends on measurement of some unique attribute of the user. They presume that these user characteristics are unique, that they may not be recorded and reproductions provided later, and that the sampling device is tamper-proof.

Two-factor authentication

Two factor authentication is authentication using any two different methods. The most popular two-factor system is a combination of hardware tokens and passwords.

Authentication profiles

Some systems authenticate users who forgot their password, especially in the context of a self-service password reset ((_label_self-service-reset)), by asking the user to type answers to one or more personal questions. What the user types at the time of authentication is compared against data stored about the user -- an authentication profile.

An authentication management system may manage authentication profile data.

Security equivalence

Processes that collect or manage authentication data may make different authenticators security-equivalent. Security equivalence means that someone in possession of one authenticator can manage another authenticator.

For example, Q&A registration makes Q&A data equivalent to the password used to authenticate and fill in the profile. Self-service password reset makes passwords equivalent to the Q&A profile that a user had to answer before being allowed to select a new password.

Identity management software infrastructure

Organizations can deploy software to more effectively manage user identity information across multiple systems.

The following sections define the possible components of an identity management infrastructure:

Meta directory

Some organizations deploy a meta directory to synchronize user and user attributes between multiple user directories.

A meta directory program is software that compares users and user attributes as defined on multiple systems, and automatically propagates changes made on an authoritative system to other systems. For example, if a user's HR record is updated with a new home telephone number, a meta directory might update the corporate e-mail system and LDAP directory with the same new information.

Directory synchronization

A directory synchronization process compares users, user groups and user attributes as they are defined on two or more systems. It applies business logic to detected differences, and automatically updates the users, user groups and/or user attributes on at least one system to match those found on others.

Meta directory software normally implements a directory synchronization process.

Enterprise single sign-on (E-SSO)

(14) Enterprise single sign-on systems consist of client software and a central database or directory, used to automatically type a user's credentials into application login prompts.

Users sign into the E-SSO client, which authenticates them against a central directory or other infrastructure (e.g., smart cards or hardware tokens).

Users launch applications using icons or a menu displayed by the E-SSO client software. The E-SSO software fetches the user's credentials from the central database, launches the desired application, and uses Windows scripting to send keystrokes representing navigation plus the user ID and password to the application.

Web single sign-on (WebSSO)

(15) Web single sign-on systems consist of an agent installed on web servers, and a central infrastructure that includes a directory and servers or logic to manage authentication and access control.

When users attempt to access a WebSSO-enabled web server or web application, the WebSSO agent redirects the user's web browser to an authentication server, where the user signs in. The web browser is then redirected back to the requested web application, and the user can access the application or web content.

When an already authenticated user accesses another web application, the agent on the web application retrieves the user's validated credentials, thus eliminating any need for the user to sign on again.

WebSSO systems also incorporate access control mechanisms, where either the agent installed on each web server, or the web applications themselves (using an API), may check whether a user is entitled to access data or functions.

Most WebSSO systems also include a distributed administration interface, for defining new user accounts and managing existing ones.

Access management system

An access management system streamlines the processes of creating, updating and deactivating accounts, as defined in (_label_access-management).

Authentication management system

An authentication management system streamlines the processes of updating passwords and managing other types of authenticators, as defined in (_label_auth-management).

Agent

(16) An agent is a software component that allows an access management system to create, update or delete accounts on a managed system, and that allows an authentication management system to set or validate passwords or other authenticators on a managed system.

Agents may be installed on the access management or authentication management server itself, or on the managed system.

Agents installed on the identity management server are sometimes called remote agents, because they use a remote administration software protocol understood by the managed system. Conversely, agents installed on the managed system are sometimes called local agents.

Connector

Connector is another term for agent -- see (16).

Plugin architecture

An identity management system may be extensible and customizable. One approach to extending and customizing functionality is through provision for plugin programs, which the identity management system executes under pre-defined conditions, and whose output may alter its behaviour.

Plugin programs are normally invoked using a well-defined interface, which should normally not change between successive releases of the identity management software.

Plugin programs are preferable to modifying the application logic of the identity management itself:

They cannot introduce bugs or security vulnerabilities into the identity management software.
They are external to the identity management software, and so can survive upgrades.
They can be developed and maintained using any software development tool.

Plugin program

A plugin program is a piece of software developed independently of the identity management software, which may be invoked by the identity management software to validate or acquire information, or to alter its own behaviour.

Plugin point

A plugin point is a set of conditions that cause an identity management system to invoke a plugin program. Plugin points may be enabled, disabled or configured within the identity management system.

Web access management system (WebAM)

Please see (_label_web-sso).

Access channel

Users may access the functions of an identity management system using several possible user interaction access channels. These include a web interface, a client/server interface (client GUI), login with a special account (e.g., a secure kiosk account), using e-mail, or with a telephone, through an IVR system.

For most functions of an identity management system, web and e-mail access are appropriate. For self-service password reset, other access channels may be required, because the functionality is required before a user can connect to the network or open a web browser.

Identity management server

Identity management systems normally run on their own hardware, on a dedicated server. This is the identity management server.

Examples are servers used to provide self-service password reset, password synchronization, central user administration, to manage access change authorization workflow, etc.

Managed system

(17) An identity management server manages access on and authentication to other systems, such as operating systems, databases, applications, etc. These are managed systems.

Target system

Please see (_label_managed-system).

Sub-host

An identity management system may manipulate user accounts on managed systems that are implemented as aggregates of smaller systems. Examples of aggregate systems include:

Windows 2000 domains, which contain multiple domain controllers.
Applications which include an operating system, directory and/or database.
An e-mail system which includes a global directory and local mail servers.

In these cases, it is sometimes appropriate for the identity management system to refer to a single, aggregate system, and sometimes appropriate to differentiate between its components. For example, a user may be known to exist on the system as a whole, but password updates may have to be performed on each component.

A sub-host is one component of such an aggregate system.

Fault tolerance

An identity management system is fault tolerant if:

It includes multiple, redundant servers, and continues to offer full functionality even when one of those servers ceases to function.
It detects failures in updates to managed systems, and automatically retries failed operations until they succeed.

Automatic retry

Automatic retry is a facility in an identity management system where the identity management system detects failures in updates to managed systems, and retries failed operations until they succeed.

Exponential back-off

Failure to complete an update transaction on a managed system is frequently caused by a temporary outage of that system, or the network infrastructure connecting to it. Automatic retry systems frequently implement an exponential back-off schedule, which means that there is an exponentially increasing time interval between successive automatic retries.

Audit trail

Identity management systems should maintain an audit trail of, at the very least, all security events. These include authentication attempts, change request input and authorization, access provisioning and deactivation events, password synchronization and reset, profile updates, etc.

Encrypted communication

User access to any security application, including to an identity management server, should be encrypted.

Communication between an identity management server and other network components -- such as managed systems, call tracking systems, authoritative directories, etc. should likewise be encrypted.

Encrypted storage

Sensitive data stored by an identity management system should be encrypted. This typically includes personal user profile data, passwords used to sign into and manipulate managed systems, etc.

Accountability / non-repudiation

Identity management systems should provide for accountability for user actions. This typically amounts to authentication of users before they perform actions such as submitting change requests, authorizing changes, or managing passwords. Accountability also means that such actions should be logged, and it should be difficult or impossible to alter those logs.

Non-repudiation means that once an action has taken place, a user cannot realistically claim that he did not make it.