Authentication and Identity Management, Authorization and Policy

Authentication and Identity Management

Authentication process tries to verify that the user has the claimed identity. There are three ways to verify this, commonly known as:
  1. Something the user knows, like a password or a private key
  2. Something the user has, like a magnetic card or physical key
  3. Something about the user, a physical trait, like a fingerprint or a voice print

Something You Know

Most-popular way to authenticate users is with a password. One way to do password authentication is for the user to input their password and then the host checks it against its password list. The down-side of this approach is that an intruder can steal this list of passwords and reuse it to access other hosts on the same network - passwords are all in the clear.

A smarter way is to store one-way hashes of user passwords on the host. When the user inputs their password the host calculates its one-way hash and compares this with its list. This ensures that an attacker who compromises the host cannot reuse the passwords from the list. But if some users have weak passwords the attacker can perform a dictionary attack. This attack works by taking dictionary words or their combinations, hashing them and looking for this hash on the password list.

To defeat the dictionary attack the host can hash passwords with salt before storing them. The password file now contains for each username the salt and the hash of salt+password. The salt should be a randomly chosen number out of a fairly big range of numbers. Each user should have a different salt. When the user logs in, the host retrieves their salt from the password file, adds it to the user-supplied password and checks that the hash of this matches the hash in the password file. An attacker seeking to perform dictionary attack doesn't know which users have weak passwords and has to perform the online attack (generating hashes and matching them on the fly) at least as many times as there are users of that particular host). If he performs an offline attack, where hashes are precomputed prior to the intrusion, he needs to launch the dictionary attack as many times as there are possible salt values.

Another problem with password authentication is that anyone sniffing on the network can obtain the password, since it is sent in clear. One way to deal with this is to use one-time passwords. Because such passwords would require ongoing set up at both the user and the server, we would like the subsequent passwords to somehow be derivable from the current ones. Lamport hash or S-key achieves this. It starts from the user-input password and generates a long chain of passwords where each is one-way hash of the previous one. The last password is sent to the server. When the user wants to log in they supply the password from the chain that precedes the one stored at the server. The server hashes this input, verifies the hash against the password it has stored for the user and replaces that one with the user's input. The down-side of this approach is that the chain must be periodically regenerated should it run out of passwords.

Another way to defeat sniffing is to use public/private keys for authentication instead of passwords. The host keeps every user's public key and users keep their private keys. When the user wants to log in the server sends them a random number R as a challenge. The user encrypts it with their private key and the server verifies with the user's public key.

Single Sign-On

Single Sign-On has a goal to enable users to log in just once into some service. The service will then vouch for them to other services. This service becomes an identity provider.


Passport service is implemented through browser redirections and cookies and does not require any change at the client to work. The passport server maintains the authentication information for the client. At some point the client wants to access some service, e.g., wants to buy something at an online merchant. If this is the first time this user accesses this merchant, the merchant's server will redirect the user to the passport server. The passport server will ask the user to log in - just this first time. When the user logs in the server places a cookie into the user's browser so that future accesses to the passport server do not require a login. The passport server also provides the credentials to the user's browser, to be sent to the merchant's server. The credentials assure the merchant that this user's identity has been verified. The merchant then sets a cookie in the client's browser for future accesses. The figure below illustrates this process.

Passport has a lot of problems, which have been detailed in this publication. Some that we would like to highlight are:


Cookies are placed into browser cache by servers to store some state. A server can place a cookie for themselves or for someone else (think DoubleClick). When the browser visits the server associated with the cookie its sends the cookie back to that server.

Cookies may have information about username, password, session ID, user's shopping cart, etc. They are stored by the browser in clear but they can contain information encrypted by the server. They may also contain expiration time.

To use cookies for authentication the server usually starts a session when the user logs in, then stores the session ID in the cookie. This enables user to visit the server again without logging in. When the user logs out the cookie is deleted and the session is closed on the server.

If the IDs are predictable and stored in the cookie in clear anyone can log on as someone else. To prevent this the server could encrypt the session ID.

Cookies could also be stolen and reused. To prevent this server can set expiry time on cookies. It can also bind cookies to the user's IP address.

How would one steal cookies? They could be sniffed from network traffic (they are sent in clear), stolen from the browser via cross-site scripting or via DNS poisoning, or they could remain in browser on a public machine because user forgot to sign out.

Federated Identity - Shibboleth

Federated identity mimics the Passport in the concept of having an identity provider for each user that vouches for them. Unlike in Passport, where there is one passport server, federated identity assumes that each user may have a different organization vouching for them, as long as the service provider is willing to accept this organization's assurance. In Shibboleth, there is the Where-Are-You-From service (WAYF) that knows the identity provider for each user. When the user accesses the service provider they redirect the browser to WAYF server, who redirects the access to the user's identity provider. The identity provider asks the user to log in, then provides them with credentials to be given to the service provider. Service providers form a federation with identity providers, meaning they trust each other and they exchange some shared keys. In addition to providing assurance about user's identity, an identity provider can also provide assurance about some user attributes, e.g., is this a student at USC? This assurance can be provided without divulging user's identity.

Something You Have

In this authentication the user has a physical device - a magnetic card, a key, a USB - that they use to authenticate themselves. The assumption here is that users are always in possesion of their device and they don't share it with others, but this is hard to enforce.

Something About You

In this authentication the user uses some biometric feature like fingerprint or iris scan or voice print to authenticate. Unfortunately, even these features can be faked with sufficient accuracy to trick the authentication device. And once compromised, the user cannot acquire new credentials.

Multi-Factor Authentication

Multi-factor authentication uses multiple authentication approaches to increase security. For example it may combine passwords with magnetic cards. Even if someone compromises your password remotely they still need physical access to magnetic card to authenticate. On the other hand if your magnetic card is stolen, the attacker lacks the knowledge of the password to be able to access the protected resource.

Authorization and Policy

Authorization is the decision process that should answer a question "is principal P allowed to perform action A on object O?". Principal could be a user or a computer, action could be read/write/delete etc., and an object could be a file, a folder, a database, etc. Authorization depends on authentication (establishes user identity) and on policy (defines security goals).

Access Control

Authorization is often performed through access control matrix - a matrix where rows are the objects and columns are the principals. The cells denote access rights (read, write, execute, etc.). A sample ACM is given below.

In practice such a matrix would be very large and very sparsely populated. So instead of saving it whole it is collapsed either by columns or by rows.

An Access Control List (ACL) is created from the access control OBmatrix by keeping its rows and collapsing column information into cells. For each object, the cells list the principals and the actions they can perform. A sample ACL is given below. ACLs make it easy to list all the resources and access rights for a principal, but hard to list all the principals and access rights for a given resource.

Another way to collapse an ACM is by keeping its columns and collapsing row information into the cell. This creates capabilities. An example capability table is given below. Capabilities make it easy to list all the principals and access rights for a given resource, but hard to answer a question "what are all the rights a principal has on any file".

Types of Access Control

There are many ways to assign permissions to principals. In this class we will mention the following few:


Policy defines what actions are allowed on the system, and how the system and security mechanisms should act in any situation. Policy is enforced by a variety of security mechanisms, e.g., firewalls, intrusion detection systems, access control systems, etc. Each of these mechanisms is implemented usually as a software component and may have its own vulnerabilities. It is an open research question how to prove that a set of security mechanisms and their configurations correctly and completely implement a given policy.

Bell-LaPadula Policy Model

Bell-LaPadula policy model focuses on protecting classified information from unauthorized access. It combines mandatory and discretionary access control. When deciding if a principal P can perform action A on object O it compares P's clearance with O's classification (mandatory access control) and it also checks the ACM to see if P is allowed to perform A on object O (discretionary access control). Only if both of these checks result in "yes" is access allowed.

Mandatory access control in Bell-LaPadula defines two rules:

  1. "no read-up" - a subject with lower clearance cannot access objects with higher classification
  2. "no write-down" - a subject with higher clearance cannot write objects with lower classification. System administrator can override this rule.

Biba Policy Model

Biba policy model focuses on protecting creation of sensitive information, i.e., integrity. It also deploys both discretionary and mandatory access control, but we focus here only on mandatory access control rules:
  1. "no write-up" - a subject with lower clearance cannot create objects of higher integrity
  2. "no read-down" - a subject with higher clearance cannot read objects with lower classification.

GAA: Generic Authentication and Authorization Framework

Today's security tools work independently. There is no explicit coordination between security mechanisms. There is also no way to dynamically set policy rules depending on the situation the system is facing. Security tools should implement coordinated policies that: originate from multiple sources and can adapt to dynamic changes in the environment.

Generic Authentication and Authorication (GAA) framework allows for this kind of dynamic and coordinated security solutions. GAA defines a common API that can be used by many security solutions. It relies on the authentication to prove a user's identity. It then applies extended access control lists (EACLs) to determine if the user is allowed certain action on a given object. This determination takes into account not just the user's identity but also the state of the system. The rules are enforced via security solutions. Figure below illustrates the GAA framework's operation.

GAA separates the authorization and policy (who is allowed to do what) from the authentication and enforcement process (how are users authenticated and how are security properties enforced). GAA API focuses on authorization functionalities and hides the calls to individual security mechanisms (e.g., how is key management performed, which encryption will be used, etc.)

Extended ACLs specify:

  1. Positive or negative access right
  2. Pre-conditions (when does the rule apply)
  3. Request-result conditions (these become activated when the rule is exercised - on success or on failure)
  4. Mid-conditions (these must hold during the execution of the requested operation)
  5. Post-conditions (these specify what must be true when the operation completes - on success or on failure)

For example one may define the following rule: Logins from the specified IP address range are permitted (positive access right), using either X509 or Kerberos for authentication (pre-condition) if previous login attempts <= 3 (pre-condition). If the request fails, the number of the failed logins should be updated. (post-condition). Connection duration should be less than 8 h (mid-condition).

There are four phases of condition evaluation in GAA framework. First, GAA reads EACL and obtains rules that correspond to a given object. It then checks if the pre-conditions are met and starts the execution. During execution it checks if mid-conditions are still met. After the execution it enforces post-conditions and request-result conditions, which may change the system state.

Dynamic policy rules enable dynamic response to attacks, e.g., lockdown or isolation of critical systems, increased access checks, etc.