The Management of Identity by the Federation

Augustin De Miscault

Abstract

A user's identity can be defined as a set of personal attributes. For example, a forename, surname and date of birth are personal attributes. These attributes can be used to define an identity.

Keywords

Ad hoc architecture

Chief information security officer (CISO)

Extensible markup language (XML)

Hypertext transfer protocol (HTTP)

OAuth 2.0

SAML 2.0

Security assertion markup language (SAML)

Simple object access protocol (SOAP)

Websingle sign-on (WebSSO)

2.1 The fundamentals of the identity federation

2.1.1 Identity: a set of personal attributes

A user's identity can be defined as a set of personal attributes. For example, a forename, surname and date of birth are personal attributes. These attributes can be used to define an identity.

Each application defines its users' identities according to its needs (see Figure 2.1).

For example, an email application defines an identity via a login, password, a surname and a forename. An e-commerce application can define an identity via an email address, a password, a surname, a forename, an address and a date of birth.

The user possesses an identity on each application. For example, in Figure 2.1, Anne Vanden has an identity on the email application (avanden; *avanden$; Vanden; Anne) and an identity on the e-commerce application (avanden@mail.com; %ava82; Vanden; Anne; 7 Beach Road; 31/03/1982).

From a technical perspective, a user account on an application can be considered equivalent. A user, then, possesses as many identities as they have accounts.

The user's identifier is an identity attribute. The identifier has to be unique. The identifier allows the application to find one user out of all of the application's users. For example the login (avanden) is the identifier for Anne Vanden on the email application, and the email address (avanden@mail.com) is the identifier for Anne Vanden on the e-commerce application.

2.1.2 Identity federation: propagating identity

Identity federation allows a set of applications to refer to a single user, while the user is known by different identities on each application.

By extension, associated with the subject of identity federation, are mechanisms which can be used to propagate the use of an identity from one application to another on the Internet (see Figure 2.2).

2.1.3 The concepts of identity federation

All of the standards for identity federation are based on an identity provider (IdP) and the service providers (SP) (see Figure 2.3).

The IdP authenticates the user and propagates their identity.

Facebook and monservicepublic.fr are examples of IdPs.

The SP protects the application. The SP delegates the user's authentication to the IdP. The SP requests the user's identifier and attributes from the IdP. The SP is linked to one or several IdPs. Foursquare is an example of a SP linked to Facebook. Online tax services, Chèque Emploi Service Universel (CESU) and Prestation d'Accueil du Jeune Enfant (PAJE) are examples of SPs linked with monservicepublic.fr.

The IdP and SPs exchange an identity token. The identity token contains the user's identifier and the user's attributes.

Each identity federation standard defines the format of the token and the request-response protocol in order to obtain and consume the identity token. Figure 2.4 shows an example of an identity federation mechanisms with the following steps:

1) The user seeks to access an application.

2) The SP intercepts the request. The user is not yet authenticated on the SP. The SP requests that the IdP authenticate the user and propagate the user's identity.

3) The user is not yet authenticated on the IdP, which requests that the user authenticates.

4) The user authenticates.

5) The IdP validates the authentication and transmits the identity token containing the user's identifier and attributes to the SP.

6) The SP validates the identity token and extracts the identifier and attributes. The user accesses the application.

2.1.4 Trust: a prerequisite for identity federation

Identity federation is based on a relationship of trust between the IdP, the SPs and the user:

- the SPs trust the IdP in his ability to authenticate the user and propagate reliable and up-to-date identity attributes. For example, if the IdP transmits the user's address and telephone number, the SPs expect this information to be accurate and up-to-date;

- the IdP trusts the SPs with regard to what they decide to do with the user's identity. For example, the IdP ensures that the SPs do not send personal information to third parties without the user's consent;

- the user trusts the IdP's ability to protect their identity and privacy. These relationships of trust are conceptualized by the circle of trust (see Figure 2.5);

- the circle of trust is centred on an IdP. The IdP propagates the user's identity to the SPs;

- the circle of trust may have a governance structure. The IdP and the SPs within a circle of trust are committed to complying with a set of rules and procedures which dictate the way in which exchanges must be carried out;

- the circle of trust can help to contractualize trust.

2.1.5 Stakeholders in identity federation

Identity federation involves several stakeholders:

2.2 The technical limitations of solutions before identity federation

Identity federation enables several technical limitations to be overcome. Namely:

- using WebSingle Sign-On (WebSSO) and propagating the identity beyond a Domain Name Service (DNS) domain;

- propagating the user's identity during the use of web services.

2.2.1 Using WebSSO beyond a DNS domain

2.2.1.1 The advantages of WebSSO: ergonomics, security and administration

If a user seeks to access several applications, typically, each application requires authentication.

This set-up has several drawbacks (see Figure 2.6):

- the user must be authenticated on each of the applications;

- the user has a password for each application;

- the application manager has to manage the users' login/passwords. They must, for example, define a password policy, manage the resetting of passwords in case of loss, and ensure that the password is protected;

- the CISO cannot centralize access management. The application managers are the only ones in charge of access management.

WebSSO is set up within companies to remedy these drawbacks (see Figure 2.7).

The steps of WebSSO are as follows (see Figure 2.7):

1) The user seeks to access an application. A WebSSO agent, in front of Web application, intercepts the request.

2) The WebSSO agent redirects the user toward the authentication server.

3) The user authenticates on the authentication server which places a session cookie4 on the user's browser. The cookie contains the user's identifier (if the user already has a valid session cookie for the authentication server, then this step is skipped).

4) The authentication server redirects the user to the application. The WebSSO agent, in front of Web application, intercepts the request, verifies the cookie's validity (signature and expiration date) and retrieves the user's connection...