Signing on to a service such as e-mail involves entering a username and password: your credentials. What happens behind the scenes when you enter your credentials is called authentication: the computing service in question establishes that you are the owner of a valid account and gives you access to it. Managing who gets access to which computing services, and with what privileges, is called authorization. Typically, the service manager authorizes the access and privileges of individuals and groups.

For authorization to work, information about individuals has to be associated with the groups they belong to and roles they play in the organization – a process known as identity management. This ultimately involves information managed by the organization's HR service. This situation is summarized in figure 1.

Several years ago in the course of an average working day a typical CERN user would have to authenticate many times using many different credentials. First a login and password were required to unlock the Windows desktop, then the user had to type in another login and password to unlock the Linux desktop or session. Credentials were also needed to read e-mails, use administrative applications, and submit a CHEP presentation on Indico, for example. Today the situation is better but still not optimal. Many applications use the same credentials – an improvement.

CERN authentication

The aim of the CERN authentication service is to provide a single sign-on for CERN applications, using a unique central account database.

The first step to achieving this was to reduce the number of user databases. Cutting the number of login and password pairs to remember has a direct impact on user satisfaction and on security: it is easy to remember one password.

Centralizing the user database in one location avoids leaks and reduces potential security holes. It also helps to provide extended services like external accounts management (using a lightweight registration process for non-CERN users). The centralized database of CERN users also provides groups and roles membership, to enhance access rights to resources.

To further improve security, the centralized database means that access by a user to all applications can be blocked with just one click. Users can give others access to resources by means of permissions and delegation instead of sharing credentials: shouting a password in the corridor is no longer an option.

Authentication methods and user data

The CERN Single Sign On (SSO) infrastructure provides different authentication methods, with different security levels:

• Classic web forms, where users type in the login and password. Depending on the browser features, the login and password can be saved locally for later use.

• Windows integrated authentication. The current Windows session token is reused to authenticate the user, without having to retype credentials. The security of Windows desktop sessions has also been increased by deploying a strong screen-lock policy: screen savers with password locking have been forced on all Windows desktops with a short time out, to avoid users leaving their screens unlocked for long periods of time.

• Certificates. Authentication can be made using a certificate provided by the CERN Certification Authority (CA) or any Grid-trusted CA member. Depending on the security level required, SmartCard tokens with pin codes can also be used.

The calling application can select all or some of the authentication methods. For example, to ensure maximum verification, experiment controls can request operators to authenticate only with certificates on SmartCards.

The single-sign-on infrastructure can also provide information about the user needed for the calling applications. All account information associated with the user is returned to the calling application, such as name, e-mail address and building. Membership of groups and mailing lists is also returned, so that the calling application can rely on central group membership to handle access control. Instead of a "per application dedicated role system" we now have a centrally managed group management on which all applications can rely.

Authentication overview

Figures 2–4 show what users can expect to see with the CERN SSO service:

• The user opens a website that requires authentication and is redirected to the SSO form (figure 2).

• His/her details and groups membership are available to the application, and can be used, for example, to restrict access to some pages (figure 3).

• Finally, clicking on the Logout button will disconnect the user from all opened applications (figure 4).

Identity and service providers

The SSO system has two components: the Identity Provider and the Service Provider.

The Identity Provider checks the identity of users and supports various authentication methods (figure 5). It can be seen as the server side of the SSO system. It verifies credentials and loads user information for the calling application, using so-called "claims" or "attributes". Note that each application can retrieve a different set of attributes, depending on the confidentiality level required.

The CERN implementation of the Identity Provider is based on Microsoft Active Directory Federation Services (ADFS). ADFS is an extension of the Microsoft Active Directory central authentication database, using the WS-Federation Passive Requestor Profile standard, based on SOAP (Simple Object Access Protocol) web services (see http://technet2.microsoft.com/windowsserver/
en/technologies/featured/adfs/default.mspx
).

Authentication is a highly critical service so the production service is hosted in the Computer Centre's critical area, on load-balanced servers to maximize availability.

The Service Provider is the client side of the SSO system (figure 6). It enables users to access web applications after they have been successfully verified by the Identity Provider. The Service Provider can be a Microsoft Internet Information Service (IIS) module, an Apache module or an application module – some Java classes, for example.

On Windows- and IIS-hosted websites an IIS ADFS module comes with Microsoft Windows 2003 R2 as an additional component. It can easily replace an existing authentication system using basic or NTLM authentication.

On Linux-, Unix- and Apache-hosted websites, the Shibboleth Apache module can be used. Shibboleth is an open-source middleware software (see http://shibboleth.internet2.edu). The upgrade is quite simple because the classic Apache configuration files for access control are still used and can be kept; only the authentication module needs to be replaced.

In both cases moving to an SSO solution is a straightforward procedure. Only small configuration changes are required, and it is transparent for all applications that rely on the default authentication systems provided by web servers.

Non-web applications

The CERN SSO classic service can only be used for web-based applications. For those that are not web based, a dedicated SOAP web service is provided for verifying credentials, and retrieving user information and group memberships.

This service requires some coding on the client side: a SOAP client, sending credentials to the web service and decoding return codes accordingly, is needed. Note that this implementation is not standard but a CERN-specific implementation based on SOAP standards.

The next steps

Today many of CERN's central services already use the SSO system on Windows and Linux platforms. Several pilots are also running on various Linux distributions as well as on Solaris for different services, and interest in the system is growing quickly. The fact that interaction between Windows and Unix is working opens up many possibilities, and it is the only way to achieve a truly viable single-sign-on solution.

At the same time, CERN also needs to improve and clarify the management of accounts. It is necessary to clean up, and ensure that each user has only one account for all services. Finally, it is important that control over access to resources is centrally managed. Figure 1 shows an overview of the way in which accounts and groups will soon be managed at CERN.