The identity lifecycle involves a series of different processes, each with its own essential role. These processes can be classified into identity creation and validation, authentication, and identity change management. In Part 1 of this blog series we discussed how an identity is created and validated within the enterprise. In this post we will discuss how registered identities are used to gain access to systems, applications and data.

Authentication: Using the Identity

The initial creation of an identity within the enterprise is a one-time, workflow-based process, which results in the registration of an identity and an issuance of credentials associated with that identity.  Authentication is a transactional process, in which the end-user who wishes to gain access to enterprise systems, applications, or data demonstrates that he is entitled to permissions, rights, or other authorities granted by the enterprise to the registered identity he claims.

Credentials presented for online access are usually classified into three categories or factors:

• Something you know (username, password, PIN)
• Something you have (card, fob or other device, or cryptographic key)
• Something you are (biometric measurement)

Depending on the sensitivity of system or data being accessed and on the risk of compromise perceived by the enterprise, authentication may be single-factor, two-factor, or multi-factor, and selected from any combination of categories above. One of the key measures of the strength of the authentication mechanism is usually measured as entropy (how often the credential changes). NIST SP 800-63-1 defines entropy for authentication as a degree of uncertainty that an attacker faces as he tries to impersonate a legitimate user. As we noted in Part 1, the strength of authentication credentials is independent of the extent to which the enterprise is certain of the identity linked to the credentials.

Authentications can be simple or complex, and can consist of a single step or include several steps. At each step the user presents an alphanumeric token (remember, we are using the word token to refer to a string of characters, not a physical device at this point), which is validated against a token stored by enterprise at registration or generated as part of the authentication transaction. In some cases, such as username or password, the token may be a memorized character string; in other cases, such as one-time passcode or biometric, it may be a result of computation, measurement, or a combination of the two. In cases where a token, such as a password or cryptographic key, is stored on the device and transmitted to the enterprise, the overall strength of the authentication is completely dependent on how a user authenticates himself to the device that stores and transmits the token. For example, if a password is stored in a browser, then anyone who has access to the browser can authenticate himself by transmitting the password. This is also true for browser-based PKI certificates – the certificate itself is not the authentication, it communicates that the authentication was completed –which may be as simple as logging onto the computer with username and password.

Although most users have experience with authentication transactions that behave the same way every time, this need not be the case. The authentication process can be driven by rules that reflect the enterprise’s evaluation of risk presented by the identity associated with the credentials, by the environment (e.g., location of attempted login), or by the nature of a transaction (e.g., electronic prescription for a particular type of drug, size of financial transaction). For example, a user may be challenged with single-factor authentication if he attempts to login from a known computer and a known IP address, but may face two-factor authentication if logging in from an unknown machine. The authentication rules can be as simple or as complex as needed to meet the risk management objectives of the enterprise.

The credentials are usually captured by an access manager that then controls a session, transaction, or activity based upon the business rules established by the organization. When an individual authenticates successfully, the access manager controls their access to downstream resources, data, and business processes. Depending on business rules, it may invoke additional authentication during the course of a session. The access manager also redirects those who fail authentication to an alternative process.

In Part 3 of this blog we will look at the process for managing changes in the registered identity.