Information Security Today Home

New Books

Oracle Identity Management; ISBN 9781420072471
Security without Obscurity: A Guide to Confidentiality, Authentication, and Integrity by J.J. Stapleton; ISBN 9781466592148
The Complete Book of Data Anonymization: From Planning to Implementation by Balaji Raghunathan; ISBN 9781439877302
Mechanics of User Identification and Authentication; ISBN 9781420052190
Security for Service Oriented Architectures by Walter Williams; ISBN 9781466584020

Authentication, Authorization, and Accounting

by Dobromir Todorov

Whether a security system serves the purposes of information asset protection or provides for general security outside the scope of IT, it is common to have three main security processes working together to provide access to assets in a controlled manner. These processes are:

  1. Authentication: Often referred to as Identification and Authentication, determining and validating user identity.
  2. Authorization: Providing users with the access to resources that they are allowed to have and preventing users from accessing resources that they are not allowed to access.
  3. Accounting: Providing an audit trail of user actions. This is sometimes referred to as auditing.

The following sections discuss these three processes and the relationship between them.

Identification and Authentication
A computer system comprised of hardware, software, and processes is very often an abstraction of an actual business model that exists in the real world outside the computer system. A financial application, for example, can be considered a model of actual financial relationships between actual organizations and individuals. Every element of the actual financial relationship can be projected onto the computer model (financial application), and then the computer model can be used to determine the outcomes of financial interactions between components of the actual system projected into the computer model.

Actual individuals using a computer system are typically humans (and sometimes applications or services) that exist outside the system. The user ID is a projection of an actual individual (or application or service) into the computer system. The computer system typically uses an abstract object, called a user account, which contains a set of attributes for each actual individual. The object has a name (user ID or logon ID) that is used to represent the abstract object to the system. Additional attributes of the object may include the full name of the actual user, the department for which he is working, his manager and direct reports, extension number, etc. Objects may or may not have credentials as their attributes. Apart from the user ID or logon ID, a security system will typically assign users an internal number (Security Identifier) that is used by the system to refer to the abstract object.

Establishing a unique abstract object in the form of a user account for each individual who will access resources in a computer system is very important. This object is used to identify the user in the system; this object is referred to by the system when user access to information assets is defined, and the system will also trace user actions and record an audit trail referring to the actual user by his abstract object ID. The user ID is therefore the basis for access control and it also helps to implement accountability. Hence, it is essential to have a separate user ID for each user, because each individual has specific access requirements and should be individually kept accountable for his actions.

The process of authentication is often considered to consist of two distinct phases: (1) identification and (2) (actual) authentication.

  1. Identification provides user identity to the security system. This identity is typically provided in the form of a user ID. The security system will typically search through all the abstract objects that it knows about and find the specific one for the privileges of which the actual user is currently applying. Once this is complete, the user has been identified.
  2. Authentication is the process of validating user identity. The fact that the user claims to be represented by a specific abstract object (identified by its user ID) does not necessarily mean that this is true. To ascertain that an actual user can be mapped to a specific abstract user object in the system, and therefore be granted user rights and permissions specific to the abstract user object, the user must provide evidence to prove his identity to the system. Authentication is the process of ascertaining claimed user identity by verifying user-provided evidence.

The evidence provided by a user in the process of user authentication is called a credential. Different systems may require different types of credentials to ascertain user identity, and may even require more than one credential. In computer systems, the credential very often takes the form of a user password, which is a secret known only to the individual and the system. Credentials may take other forms, however, including PIN numbers, certificates, tickets, etc.

Once the individual has been authenticated, the system will associate an initial process to the user (a user shell), and the user will be able to launch other processes. All the processes launched by the user access resources (information assets) using the identity of the user, which has already been ascertained by the system.

User identification and authentication are typically the responsibility of the operating system. Before being allowed to create even a single process on a computer, the individual must authenticate to the operating system. Applications and services may or may not honor authentication provided by the operating system, and may or may not require additional authentication upon access to them.

There are typically three components involved in the process of user authentication (Figure 1.1):

Figure 1.1. Components of a user authentication systems.
  1. Supplicant: The party in the authentication process that will provide its identity, and evidence for it, and as a result will be authenticated. This party may also be referred to as the authenticating user, or the client.
  2. Authenticator: The party in the authentication process that is providing resources to the client (the supplicant) and needs to ascertain user identity to authorize and audit user access to resources. The authenticator can also be referred to as the server.
  3. Security authority/database: A storage or mechanism to check user credentials. This can be as simple as a flat file, or a server on the network providing for centralized user authentication, or a set of distributed authentication servers that provide for user authentication within the enterprise or on the Internet.

In a simple scenario, the supplicant, authenticator, and security database may reside on the same computer. It is also possible and somewhat common for network applications to have the supplicant on one computer and the authenticator and security database collocated on another computer. It is also possible to have the three components geographically distributed on multiple computers.

It is important to understand that the three parties can communicate independently with one another. Depending on the authentication mechanism used, some of the communication channels might not be used - at least not by an actual dialogue over the network. The type of communication and whether or not it is used depends on the authentication mechanism and the model of trust that it implements.

For example, authentication protocols such as Kerberos will typically involve direct communication between the supplicant and the security server and the supplicant and the authenticator; but with regard to user authentication, there is no direct communication between the authenticator and the security server. Still, messages from the supplicant to the authenticator contain information sent by the security server to the authenticator.

Authorization is the process of determining whether an already identified and authenticated user is allowed to access information resources in a specific way. Authorization is often the responsibility of the service providing access to a resource.

For example, if a user tries to access a file that resides on a file server, it will be the responsibility of the file service to determine whether the user will be allowed this type of access. Authorization can provide for granular control and may distinguish between operations such as reading or writing to a file, deleting a file, launching an executable file, etc.

Before authorization takes place, the user must be identified and authenticated. Authorization relies on identification information to maintain access control lists for each service.

Operating systems typically facilitate the process of authorization by providing authorization tools to applications. The operating system will typically provide for a security kernel (or an operating system Security Reference Monitor) that can be used to mediate access to resources by making sure that the operation is authorized. Alternatively, applications can implement their own authorization model, and Security Reference Monitor.

A user can be authenticated using a certain identity but he can request to be authorized to access a resource under a different identity. When the user explicitly requests this upon access to an application or resource, this is typically referred to as authorization identity. When this is performed by an application or service acting on behalf of the user, this is referred to as impersonation.

In the case of impersonation, a user may posses an authentication identity that has been ascertained by the authentication process. In addition, the user may temporarily or permanently use an authorization identity, if the user is authorized by the operating system or application to impersonate another user by assuming the other user's identity. Impersonation is very useful in client/server computing where a server application running under a server account can access resources on behalf of users connecting to that server. Impersonation also allows a user to connect to a server using somebody else's broader or more restricted access permissions.

User Logon Process
Authentication and authorization work very closely together, and it is often difficult to distinguish where authentication finishes and where authorization starts. In theory, authentication is only supposed to ascertain the identity of the user. Authorization, on the other hand, is only responsible for determining whether or not the user should be allowed access.

To provide for the logical interdependence between authentication and authorization, operating systems and applications typically implement the so-called user logon process (or login process, also sign-in process). The logon process provides for user identification; it initiates an authentication dialogue between the user and the system, and generates an operating system or application-specific structure for the user, referred to as an access token. This access token is then attached to every process launched by the user, and is used in the process of authorization to determine whether the user has or has not been granted access. The access token structure sits in between user authentication and authorization. The access token contains user authorization information but this information is typically provided as part of the user identification and authentication process.

The logon process can also perform non-security-related tasks. For example, the process can set up the user work environment by applying specific settings and user preferences at the time of logon.

Users are responsible for their actions in a computer system. Users can be authorized to access a resource; and if they access it, the operating system or application needs to provide an audit trail that gives historical data on when and how a user accessed a resource. On the other hand, if a user tries to access a resource and is not allowed to do so, an audit trail is still required to determine an attempt to violate system authorization and, in some cases, authentication policies.

Accounting is the process of maintaining an audit trail for user actions on the system. Accounting may be useful from a security perspective to determine authorized or unauthorized actions; it may also provide information for successful and unsuccessful authentication to the system.

Accounting should be provided, regardless of whether or not successful authentication or authorization has already taken place. A user may or may not have been able to authenticate to the system, and accounting should provide an audit trail of both successful and unsuccessful attempts.

Furthermore, if a user has managed to authenticate successfully and tries to access a resource, both successful and unsuccessful attempts should be monitored by the system; access attempts and their status should appear in the audit trail files. If authorization to access a resource was successful, the user ID of the user who accessed the resource should be provided in the audit trail to allow system administrators to track access.

About the Author

From Mechanics of User Identification and Authentication: Fundamentals of Identity Management by Dobromir Todorov. New York: Auerbach Publications, 2008.
Subscribe to
Information Security Today

© Copyright 2008-2014 Auerbach Publications