4 Authentication and Authorization Services

4.1 Authentication and Authorization Services

The development of the CESNET2 network and its applications posed new requirements on the authentication and authorization services.

4.1.1 The Central Authentication and Authorization System

The Central Authentication and Authorization System (CAAS) was implemented in 2001 to support integrated administration of users, resources and services, and access rights within the research projects. Since then, the CAAS provides for authentication and authorization services to WWW applications and access control for the backbone routers and other equipment. In 2003 the system has been extended to support control of terminal access to host computers and access to some centrally managed services (e.g., e-mail).

Architecture

Figure 4.1: CAAS Architecture

The CAAS data are stored in several LDAP servers. In 2003 we upgraded the existing installations from iPlanet Directory Server version 4.1 to Sun ONE Directory Server version 5.2. The master server is used for active data management through the WWW interface. Data modifications are replicated on-line to replicas that serve authentication and authorization requests sent by individual network services.

Main replicas are operated on hosts ldap1.cesnet.cz, ldap2.cesnet.cz, and ldap3.cesnet.cz that are located in important network nodes (Prague, Brno, Ostrava). TACACS+ servers running on these hosts provide access control services to backbone nodes (NAS). Remaining network services that use CAAS (HTTP servers, CESNET IMAP server, shell access to operating systems...) communicate with the replicas via the secured LDAPS protocol.

WWW interface for CAAS administration

WWW interface for CAAS management is built upon Perl libraries perlOpenLDAP (the LDAP protocol), myPerlLDAP (object oriented interface to LDAP data objects), and myAppFramework and myForms (for WWW applications programming). The presentation level, appearance, and localization is controlled by XSLT stylesheets. Most of the applications are localised to both Czech and English languages. The run-time environment for the applications is provided by the Apache HTTP server with the mod_perl module operated on a dedicated host (see [Sov02]). Secured LDAPS protocol is used for the communication between the application and the master LDAP server.

Two new applications have been developed in 2003: the group management application enabling group managers to modify their groups' membership lists. The user management application has been created for the Human Resources Department personnel.

CAAS Clients

The CAAS was deployed to serve various access control clients. Backbone nodes enforce access control based on the communication with TACACS servers. The access control rules and authentication data are stored in the CAAS LDAP database. WWW applications are served by our auth_ldap and auth_ldap_x509 Apache modules. WWW users can be authenticated either by their personal X.509 certificate or by their user name and password. Both authentication methods map the user to a corresponding LDAP entry which is then used for an authorization decision. Shell/terminal access to operation system services is controlled by the standard PAM-LDAP module.

4.1.2 CAAS Reconfiguration

After three years of continuous operation, the CAAS was substantially reconfigured in 2003. We upgraded the LDAP servers, increased the number of replicas and dedicated the master server exclusively to data modification. The reconfiguration process was also an opportunity to change the data information tree suffix. We have moved from the original "classic" suffix o=ten.cz based on ITU X.500 recommendation to the "modern" directory component-based format - dc=cesnet,dc=cz. The new suffix should facilitate integration of our directory services into the national and international contexts. At the same time, all of the LDAP servers were moved from the ten.cz DNS zone to the cesnet.cz zone.

The reconfiguration was challenging not only for technical reasons but mainly for its organisational demands. Uninterrupted operation of all CAAS services during the whole period of reconfiguration was an absolute requirement.

We accomplished the reconfiguration in the following steps:

New master server installation on a new server.
Creation of DNS aliases for all LDAP servers in the ten.cz zone pointing to new names in the cesnet.cz zone.
Sequential re-installation of both existing LDAP servers so that all the time at least one of them was providing CAAS services. The servers were initialised with the new DNS names.
The original master database was write-locked and exported.
The exported data was modified to reflect the suffix change.
The modified data was imported to the new master database.
The replicas were initialised for the new suffix.
New master database was write-locked. At this point of time the CAAS servers were accessible both under the new and old DNS names. The data was stored under both suffixes.
The administrators of all services were asked to reconfigure their systems so that they use the new DNS names and the new suffix.
After the reconfiguration of the dependent services the old suffixes were read-locked. Thanks to the excellent cooperation of all parties this step was finished in two days.
The new master server was opened for data modification.
Installation and initialisation of the third replica.

4.2 Certificate Authority CESNET CA

Experience from the deployment of Public Key Infrastructure (PKI) gained by the support of Czech users and researchers of the DataGrid project and the pilot PKI project for CESNET members led to a new remarkable achievement. The CESNET Certification Authority (CESNET CA) was officially opened for the Czech academic community on April 1st, 2003.

The extension of the user community mandated the creation of a new certification policy - CESNET CA Basic Level Certificate Policy and modifications to the CESNET CA Certificate Practice Statement version 1.2. These documents reflect the requirements specified within the DataGrid project as well as the results of the pilot project that provided PKI services to selected universities.

Our experience gained from operating a certification authority open to a wide academic community positively influenced the work of DataGrid's WP6-CA Managers workgroup. We are so far the only member of this group running such an open CA - all others are providing CA services just within their grid projects. It was only by the end of 2003 that the possibility of incorporating other open certification authorities started to be discussed. We believe our active cooperation within the group will help this process to continue without major obstacles.

The DataGrid project was finished by the end of 2003. The original WP6-CA Managers workgroup will continue its work as the Policy Management Authority, being part of the new EGEE project. We intend to continue the active cooperation on this new platform aiming towards the best services to our users.

As a consequence of opening the CESNET CA to the users outside the grid projects, we had to increase the availability of the Registration Authority (RA) - the workplace intermediately serving the users. We prepared a new release of the RA software that enables concurrent access of several RAs to a shared database. The data are managed in an LDAP server. The main reasons for choosing LDAP instead of a relational database are:

native access control provided by LDAP server up to the level of individual data items
standardized and secured network interface
the possibility of integrating RA data with other LDAP services we operate.

Three registration authorities operate for the CESNET CA by the end of 2003. All of them are located in CESNET premises in Prague. As the number of certification requests from users outside Prague increases, we intend to establish new RAs operated by CESNET member institutions in their localities. We plan to establish first two RAs outside Prague in the first half of 2004.

4.2.1 CESNET CA Services Utilization

By the end of November 2003, 12 Czech academic institutions were registered by the CESNET CA (an institution is considered to be registered when its first user sends in a certificate request). At the same time there were 175 valid certificates in operation, 51 of them being personal and 124 server certificates.

The statistics above show that the certificates are mainly used for server authentication under the SSL/TLS protocols. User certificates are used by GRID users and server administrators for authenticating the server certificate requests.

Such a situation is rather typical for open CAs operated by European NRENs. One of the main reasons is seen in the lack of applications using PKI for user authentication. To help overcome this we plan a massive deployment of the auth_ldap_x509 Apache module in the majority of CESNET WWW services. This way, we intend to make the user certificates more attractive. When the number of user certificates exceeds the "critical mass", they can be used in other applications, e.g., e-mail.

One of the long-term problems preventing a wide PKI penetration to academic networks is the management of user certificates. Students typically share computers in public computer rooms and thus cannot safely store their private keys on local hard disks. A new technology that may help to overcome this obstacle emerged during 2003 - "smart" chip cards able not only to store the private keys but also to perform cryptographic operations directly in the card's processor. The private key then never leaves the card and can be securely used even on a shared computer. These cards are a promising candidate technology for the new generation of ID cards to be issued by universities for their students and employees.

However, the new ID card technology deployment has considerable demands on both investments and organisational preparation. In a close cooperation with the ID-Cards workgroup associating issuers of university ID cards, we set as a strategic target to prepare the transition so that the PKI-enabled ID cards can be deployed within few next years.

First experiences were shared at the workshop Chip technologies for applications requiring identification and electronic signature held in Prague on December 4, 2003. The lecturers from universities, CESNET and CoProSys presented their views on the requirements and possible solutions of the issue. Some of the universities started to test SPK2.5DI cards with the aim of verifying their compatibility with the existing applications. The results of the tests, expected during 2004, will be used in the process of preparing the strategy of ID cards technology transition.

contents