Development of SASL based authentication and authorization system in AliEn

The base of the developed AliEn authentication and authorization service is SASL. RFC 2222 document [161] defines SASL as ―a method for adding authentication support to connection-based protocols‖. SASL offers a modular approach for implementing authentication and authorization service. Such an approach enables decoupling the authentication mechanism from the application protocols and allows implementing different authentication mechanisms without modification of neither the application layer protocols nor the implementation of those protocols.

Figure 5.1 demonstrates the SASL role as a layer between the application and the underlying authentication mechanism.

GSSAPI SSH TOKEN

SASL Application

SASL Library

111 based on SASL

In SASL-enabled client server application the authentication and authorization process involves the following steps. User obtains the authentication credentials and invokes the client application. The client application requests the list of supported authentication mechanisms from the server. After receiving the list from server client feeds it to the SASL library, which checks the existence of corresponding credentials on user‘s machine and chooses the concrete authentication mechanism. After client sends the name of chosen authentication mechanism to the server it initiates the authentication data exchange, so-called challenge-response negotiation. On each subsequent step the server gets the authentication data from the client, passes the data to SASL implementation library and sends back to client the data the library returns. The same process also happens on client side: upon receiving the challenge from the server, client passes that challenge to SASL implementation library and sends the returned data back to server. The authentication process finishes when the server or the client encounters a failure in one of the intermediate steps or when the server determines successful completion.

For AliEn authentication system the open-source implementation of SASL developed by Carnegie Mellon University and called Cyrus SASL [162] has been used. Cyrus SASL is a library which allows implementing authentication mechanisms as dynamically loadable plug-ins. During the authentication process the applications forward the data to Cyrus SASL, which then delivers it to the appropriate authentication plug-in. A new authentication mechanism is added by developing a corresponding plug-in. AliEn authentication methods are implemented as plug-ins for Cyrus SASL, they are written in C programming language with the use of OpenSSL and Globus GSSAPI libraries.

The AliEn service which performs the authentication and authorization of the clients is called Proxy. Proxy service intermediates the interaction between client and the central MySQL database where the information about files system, jobs, etc. is kept. It is important to mention that from the point of

112 view of Proxy service the clients are not only end-users who try to authenticate to AliEn but also all the services which need to access or manipulate the information stored in the central MySQL database.

Two authentication methods for users and also the internal authentication method which is hidden from users (called TOKEN) have been developed as SASL modules and incorporated into AliEn. The first of the user authentication methods is based on X.509 certificates [117] and uses the implementation of the GSS-API (Generic Security Services Application Programming Interface) [163] from the Globus Toolkit [61], the second method is based on 2048 bit RSA keys (so-called SSH keys) and uses the OpenSSL cryptographic library [164]. The TOKEN method is based on randomly generated unique string tokens which are used as job authenticators when they try to access the AliEn file catalogue.

Below an example of SASL based authentication and authorization in AliEn is presented by the example of the method which uses SSH keys. Before the start of SASL challenge-response the RSA key pair is generated and the public key is sent to central LDAP server of AliEn. Each time the client authenticates this key is used for the encryption of the challenge. An example sequence of steps in case of the ‗SSH‘ authentication method is following:

 Client sends (1) to Proxy service the string ‗SSH‘, the username and the user role, which for example can be ‗admin‘

 Proxy service checks the existence of the username in the central LDAP database and retrieves the public key of the user. The key is used to encrypt the 128 byte randomly generated string, which the server sends to the client (3)

 Client decrypts the data using the private key of the user and sends (4) the decrypted string back to the Proxy service.

 If that string coincides with the initial random string the Proxy service considers the authentication part finished and tries to authorise the client by checking in the LDAP database whether the user is allowed to

113 take the desired role. If the check is successful then it indicates the completion of the process by sending ‗SASL_OK‘ to the client.

Upon successful authentication and authorization the Proxy service returns to the user a temporary access token which the user has to present in order to access or manipulate the data from the central MySQL database. The token remains in user‘s possession and is valid for a limited period of time. Once the token validity period is over the client has to pass the authentication and authorization process again.

Figure 5.2 demonstrates the general authentication and authorization sequence in AliEn.

Client Server

Proxy

server LDAP Database

Request methods List of methods

SASL authentication _{user privileges}Checking

Data Data

X.509 RSA (SSH)

TOKEN

Figure 5.2. Sequence diagram of authentication in AliEn

5.2 Demonstration of the portability of the client part of AliEn to