hledat:

LDAP service for VOCE

CESNET technical report number 15/2005
also available in PDF, PostScript, and XML formats.

Jiří Sitera
November 2005

1   LDAP service for VOCE - introduction

Virtual organization (VO) is a term used for user community sharing common resources and GRID infrastructure. VOCE is a VO designed for GRID users coming from Central Europe federation - a community defined by the EGEE¹ internal structure based on regional principles (CE federation consists of Austria, the Czech Republic, Hungary, Poland, Slovakia and Slovenia).

A good starting point for getting more information about VOCE and its context is the VOCE home page at http://egee.cesnet.cz/en/voce/.

LDAP service for VOCE (VOCE LDAP) is one of VOCE infrastructure services. The VOCE LDAP service provides information about user accounts. It is currently used to set up configuration of resources inside the VO (proper gridmap file for each resource, which works effectively as a basic authorization service).

2   Quick start user guide

Current and accurate user guide is maintained on VOCE web pages (http://egee.cesnet.cz/en/voce/). Basic usage of VOCE LDAP (using LDAP-tools command line):

ldapsearch -x -H ldap://meta-ldap.cesnet.cz/ -b "o=VOCE,dc=eu-egee,dc=org"

Basic configuration of mkgridmap tool (lines in edg-mkgridmap.conf):

groupldap://meta-ldap.cesnet.cz/ou=VOCE,o=VOCE,dc=eu-egee,dc=org .voce
authldap://meta-ldap.cesnet.cz/ou=People,o=VOCE,dc=eu-egee,dc=org

3   VOCE LDAP service specification

The VOCE LDAP service provides data structures describing VOCE user base (user accounts) and their mapping to user credentials in the form of X.509 certificates (providing certificate DN). The primary goal of this service in context of the gLite middleware is to provide valid user base for resource configuration. Its basic usage currently consists in a white list of user certificates DNs allowing access to Grid resources inside the specified VO.

The VOCE LDAP service is accessible via standard LDAP protocol and conforms with expectations of gridmap file generating tools (edg-gridmapfile). It can be used for other purposes as well but only gridmapfile generation has been tested.

The VOCE LDAP service is connected to the Perun administration and management system [Perun], it is not designed to be maintained as a standalone service. When a new VOCE user is created (as a result of VOCE user registration procedure provided by Perun) new account is propagated to the VOCE LDAP.

3.1   LDAP schema and naming

The VOCE LDAP schema is based on mkgridmap software requirements. In fact this requirements mean that we are using the standard inetOrgPerson schema (RFC2798) and a very simple usage convention over this schema. The convention is a little bit strange: it is prescribed that the user certificate subject is expressed using a description attribute of the inetOrgPerson schema. So each entry is an inetOrgPerson entry but it is guaranteed that the entry contains appropriately formated description attribute in the form:

description: subject=/.......

We use extension of the inetOrgPerson schema called MetaPerson which allows us to add additional attributes. This does not interfere with mkgridmap script expectations. For explanation of additional MetaPerson attributes please see the tables below. The VOCE LDAP service also uses the standard groupOfNames schema (RFC2256) to describe VO group.

3.1.1   VOCE LDAP tree

The structure of the VOCE LDAP service data tree is rather simple (see figure). There is one subtree containing all individual user entries and one or potentially more group entries. Currently there is just one "main" group entry which forms the VO - contains all users currently considered to be valid members of the VOCE virtual organization.

The name of the VOCE LDAP tree (its root DN) is o=VOCE, dc=eu-egee,dc=org. This choice of the LDAP tree root is based on the dc naming component convention which makes use of the DNS as a source of unique and meaningful roots. Let's notice that this naming is completely separated from the LDAP tree of the METACenter LDAP service (which is using the root DN of o=meta,c=cz).

The VOCE group entry name is ou=VOCE, o=VOCE, dc=eu-egee, dc=org. This LDAP entry DN is in fact the main reference to the primary VOCE membership information.

3.1.2   LDAP entry naming

The VOCE LDAP user entry RDN (name of an entry local to the current branch of LDAP tree) is formed by an internal numeric user identifier, which is supposed to be unique. We made this decision because we don't assign a user name (login) to all VOCE members and user first and last names do not offer any clear way to form unique identifiers. Composed RDN was also an option but it was considered to be a potential problem for some clients and a descriptive RDN of user entries was not required. The numeric user identifier is provided automatically by Perun management system and is expressed by the uniqueIdentifier LDAP attribute.

3.1.3   User entry schema

Example user entry

dn: uniqueIdentifier=1182,ou=People, o=VOCE, dc=eu-egee, dc=org
objectClass: inetOrgPerson
objectClass: MetaPerson
cn: Daniel Kouril
sn: Kouril
givenName: Daniel
description: subject= /DC=cz/DC=cesnet-ca/O=Masaryk University/CN=Daniel Kouril
uid: kouril
uniqueIdentifier: 1182
o: Masarykova univerzita
status: ACTIVE

See table which explains the meaning of attributes in this schema.

3.1.4   VOCE group entry schema

VOCE group entry example:

dn: ou=VOCE, o=VOCE, dc=eu-egee, dc=org
objectClass: groupofnames
ou: VOCE
cn: VOCE
description: EGEE VOCE All-Members Group
member: uniqueIdentifier=4238, ou=People, o=VOCE, dc=eu-egee, dc=org
member: uniqueIdentifier=6755, ou=People, o=VOCE, dc=eu-egee, dc=org
member: uniqueIdentifier=6754, ou=People, o=VOCE, dc=eu-egee, dc=org
.....

VOCE LDAP group fully conforms with the standard groupOfNames schema, see RFC2256 for details.

3.1.5   Comments

• Behavior of the mkgridmap software regarding description attribute - code inspection of current implementation of mkgridmap tool shows that the first subject expressed by the description attribute is used for gridmap file generation. There is no possibility to express the fact that one user has two or more certificates (DNs). It is possible to use (multi-valued) description attribute for it's original purpose (user entry description) - all values of the description attribute are searched and first one starting with "subject=" is used. The VOCE LDAP service expresses its knowledge of multiple certificate subjects (per user) by providing multiple values of the description attribute. It is intended for use in future versions of client software.
• User account status - the VOCE LDAP service is designed to be able to express information on accounts that are in more that one state. For example if an account expires, we are able to handle this situation without removing all references to the account. We can still provide basic information about the account's existence and its properties, and express the fact that this account is currently disabled for any VOCE service. To describe the state of a user account we have the status attribute of the user LDAP entry. All entries that are not in "normal" state designated as active are removed from the primary VOCE group entry and thus effectively removed from all gridmap files.

3.2   Access policy and supported access methods

3.2.1   Access policy

Public access policy was chosen for the VOCE LDAP service - all data provided via VOCE LDAP service are accessible for any (anonymous) user or service. Yet it is desirable that the service should be used as a trusted information source (for local resource providers and their administrators) so it provides a secure access method (using SSL).

3.2.2   Supported access methods

The service supports both LDAP and LDAPS access methods. LDAP is the standard LDAP protocol and LDAPS is SSL-enabled variant. The VOCE LDAP server is running under the X.509 service certificate issued by CESNET CA (see also http://www.cesnet-ca.cz/). It should be verified by a client as a proof that the user account data are really provided and guarantied by the VOCE service.

Parameters specific to access methods described above are just port numbers, which are set to the standard values (389 for LDAP and 636 for LDAPS).

3.3   Administration

As mentioned above, the VOCE LDAP a is part of VOCE services provided by Perun. In this design the LDAP protocol is used only as a data access mechanism, it is not possible to perform any administrative tasks using the LDAP protocol. All administration tasks are done by the Perun system and its user or admin interface (web based interface) and are out of the scope of the VOCE LDAP service specification. The documentation for VOCE users (administrative tasks connected to the VOCE account life cycle) is accessible on http://egee.cesnet.cz/en/voce/ web page under the "How to join" section.

Perun uses an LDAP propagation technology which guaranties that any change in the user account state is propagated to the VOCE LDAP service within 5 minutes. See also next section.

4   VOCE LDAP service design and technical background

4.1   Architecture

The architecture of the VOCE LDAP service is based on current experience and infrastructure of MetaCenter services. Thus the core of the service doesn't lie in the LDAP server but in the Perun management service. The LDAP server is a read-only reflection of data stored and managed by Perun.

The solution for data transfer from Perun to LDAP is based on the technology previously developed and tested in context of the MetaCenter project. This solution allows for a very quick change propagation without expecting any nonstandard behavior on both sides - both the Perun database and the LDAP server. For this technology description please see [MetaLDAP2].

4.2   Primary server

The VOCE LDAP server is based on OpenLDAP software running on Debian Linux server. This server is shared with the LDAP service of MetaCenter. There is also installed the Perun update mechanism (perund daemon with appropriate scripts) on the server. The server is monitored every 5 minutes by the Nagios system and it isn't currently replicated.

4.3   Replication

As VOCE is a multinational project, LDAP service (server) replication is expected to run under different administrative domains and thus we have designed this service to allow for simple replication setup. This chapter provides basic description of a replica setup; for further information please contact the VOCE administrator.

The main reason for the replication of the VOCE LDAP service is availability. There are no performance-related problems to be expected should the VOCE LDAP service be used only for gridmap-file generation (no on-line queries).

4.3.1   How to replicate

The VOCE LDAP service update mechanism is designed to allow for a replication schema as close to the standard as possible. The VOCE LDAP server running under Perun administration acts as a master and any slave replica can be established using only standard LDAP replication techniques (no any knowledge of Perun on replicas). Each replica hosts a copy of the VOCE LDAP tree and accepts LDAP update messages from the master.

4.3.2   Replica setup

Any LDAP server can be set up as a replica (not only OpenLDAP based server). The first step is to establish a replica of the VOCE LDAP tree. The replica tree set-up is obvious from the description above, the VOCE LDAP tree data can be accessed by an ordinary LDAP query. Actual replication setup must be done on both sides (master and replica). But before this can be done both sides must agree on an authentication method. The options available are: using a shared password (over SSL channel), using X.509 service certificates on both sides, using a Kerberos service. Replication without authentication is also possible but not recommended.

References

[Perun]	Aleš Křenek, Zora Sebastianová, Jiří Sitera: Perun - management system of MetaCenter resources Technical report CESNET number 1/2004 (Czech only) http://www.cesnet.cz/doc/techzpravy/2004/perun-2.2/
[Perun2]	Aleš Křenek, Zora Šebestiánová: Perun - Fault-Tolerant Management of Grid Resources Proceedings of Cracow Grid Workshop '04, pages 133-140, 2004, ISBN 83-915141-4-5.
[MetaLDAP]	Jiří Sitera: MetaCenter LDAP service Technical report CESNET number 2/2001 (Czech only) http://www.cesnet.cz/doc/techzpravy/2001/02/
[MetaLDAP2]	Jiří Sitera: MetaCenter LDAP service - current status report Technical report CESNET number 29/2003 (Czech only) http://www.cesnet.cz/doc/techzpravy/2003/metaldap/

 

Footnotes:

1. EGEE project - see http://egee.cesnet.cz/