Recommendations for Higher Education Directories
SUPANN 2009
developped by the group
supann-tech
Update RC1.0Date: 27/11/2009
Preamble
This version of the SupAnn recommendations modifies the version 2008. The following elements have been added:
- precise details about the use of certain attributes,
- some new attributes,
- nomenclatures for the types of structures/entities and roles of individuals, and
- tables connecting the categories for people and the values for the attribute eduPersonAffiliation.
In addition to these modifications, the Semantics of the values for eduPersonAffiliation have evolved significantly in order to conform international compatibility standards, especially in the context of identity federations.
Table of contents
Preamble ...... 3
SupAnn 2009 Recommendations...... 7
1 Context, objectives, methods ...... 7
1.1 Context ...... 7
1.2 Objectives ...... 7
1.3 From SupAnn version 1 to SupAnn 2008...... 8
Obsolete attributes or values ...... 8
New elements ...... 9
Modifications in the use of certain attributes ...... 9
1.4 From SupAnn 2008 to SupAnn 2009...... 9
Compatibility ...... 9
Modifications of the existing attributes ...... 9
New attributes ...... 10
New labels ...... 10
New nomenclatures ...... 10
Miscellany ...... 10
1.5 Process for developing the SupAnn recommendations ...... 10
Information sources, stakeholders ...... 10
Modification of the recommendations ...... 11
Principles guiding the development of the SupAnn recommendations ...... 11
1.6 Conformity to legal regulations ...... 11
2 Technical choices ...... 12
2.1 The LDAP protocol ...... 12
2.2 Nomenclatures ...... 12
Nomenclatures used in SupAnn ...... 12
SISE...... 12
CNU...... 12
REFERENS ...... 13
UAI (formerly RNE) ...... 13
Labintel ...... 13
SIRET ...... 13
SUPANN ...... 13
2.3 Attribute Labeling ...... 14
Attribute labels...... 14
2.4 Multiple profiles, composite attributes...... 15
Multiple profiles...... 15
Composite attributes ...... 16
3 Classes, Attributes, Directory Information Trees (DIT), Naming ...... 16
3.1 Classes and their attributes ...... 16
Classes used in the SupAnn directory schema ...... 16
Attributes used in each class ...... 18
Attributes for structures ...... 18
Attributes for people...... 19
Attributes for groups ...... 22
3.2 DIT, naming...... 22
3.3 Graphic representation of the classes and the DIT ...... 23
4 Representation of the structures ...... 25
4.1 The structures in the DIT ...... 25
Entity placement in the DIT...... 25
A special case: an institution's entry...... 26
4.2 Description of the institution...... 26
4.3 Description of the entities inside an institution ...... 26
5 Representation of people...... 28
5.1 Introduction ...... 28
5.2 Common profiles...... 28
List of the attributes for the "common profile"...... 28
5.3 Student profiles ...... 29
List of the attributes for the "student profile" ...... 29
5.4 Staff profiles ...... 30
List of the attributes for the "staff profile" ...... 30
5.5 Identifiers for people ...... 30
6 Representation of groups...... 30
DIT...... 31
Attributes of the class, groupOfNames ...... 31
Attributes of the class, supannGroupe ...... 31
7 Attribute descriptions ...... 31
cn (common name)...... 31
dc (domainComponent)...... 32
description...... 32
displayName...... 33
eduOrgHomePageURI...... 33
eduOrgLegalName...... 33
eduOrgSuperiorURI...... 34
eduOrgWhitePagesURI...... 34
eduPersonAffiliation...... 34
eduPersonNickname...... 35
eduPersonOrgDN...... 35
eduPersonOrgUnitDN...... 36
eduPersonPrimaryAffiliation...... 36
eduPersonPrimaryOrgUnitDN...... 36
eduPersonPrincipalName...... 37
facsimileTelephoneNumber...... 37
givenName...... 38
l (locality)...... 38
labeledURI...... 38
mail...... 38
mailForwardingAddress...... 39
member...... 39
mobile...... 39
o (organization)...... 40
ou (organizational unit)...... 40
owner...... 40
postalAddress...... 40
preferredLanguage...... 41
sn (surname)...... 41
supannActivite...... 41
supannAffectation (obsolete)...... 42
supannAliasLogin...... 42
supannAutreMail...... 42
supannAutreTelephone...... 43
supannCivilite...... 43
supannCodeEntite...... 43
supannCodeEntiteParent...... 43
supannCodeINE...... 44
supannEmpCorps...... 44
supannEmpId...... 44
supannEntiteAffectation...... 45
supannEntiteAffectationPrincipale...... 45
supannEtablissement...... 45
supannEtuAnneeInscription...... 46
supannEtuCursusAnnee...... 46
supannEtuDiplome...... 47
supannEtuElementPedagogique...... 48
supannEtuEtape...... 48
supannEtuId...... 49
supannEtuInscription (composite attribute)...... 49
supannEtuRegimeInscription...... 50
supannEtuSecteurDisciplinaire...... 51
supannEtuTypeDiplome...... 51
supannGroupeAdminDN...... 51
supannGroupeDateFin...... 52
supannGroupeLecteurDN...... 52
supannListeRouge...... 52
supannMailPerso...... 52
supannOrganisme (obsolete)...... 53
supannParrainDN...... 53
supannRefId...... 53
supannRole (obsolete)...... 54
supannRoleEntite (composite attribute)...... 54
supannRoleGenerique...... 54
supannTypeEntite...... 55
supannTypeEntiteAffectation...... 55
telephoneNumber...... 56
title...... 56
uid...... 56
userCertificate...... 57
userPassword...... 57
SupAnn 2009 Recommendations
1 Context, objectives, methods
1.1 Context
Today, Information and Communication Technologies (ICT) play an integral role in the operations of institutions of higher education. The digital services and resources that can be accessed by students, teachers, researchers and administrative personnel cover all functional domains.
An institution's digital services and resources are generally accessible via a kind of digital workspace, Intranet or the Internet. Access via the Internet offers the possibility of mobility, telecommuting and inter-institutional resource sharing. It also allows courses to be offered to a wider population via Open and Distance Learning programs, and it reinforces the socio-economic fabric, thus reinforcing the relationship between the institution and the general public.
Facilitating the access to an institution's digital services and resources constitutes a strategic advantage, but this objective must not preclude the need to control the access to certain resources that should be protected, accessible only to duly authorized individuals. Controlling access to resources and services is generally implemented by mechanisms for identifying, authenticating and managing the authorization using a data set managed by a directory database.
Initially established for access control functions and white pages, directory databases have seen the list of applications and services that depend on them grow. Directories now occupy a key place in the "Global Information Systems" (GIS) of many institutions. The correct functioning of the Information System depends on the directory's quality, including its completeness, accuracy and reliability.
For diverse reasons (e.g., data readability, application portability and facilitation of inter-institutional exchanges), it is necessary for directory frameworks to be coherent. A set of normative documents (RFC LDAP), which were developed on the international level, established an initial framework for directory implementation. This initial effort had to be completed to satisfy the specificities of particular communities. For the community of European Higher Education Institutions (HEI), the first recommendations, called SupAnn version 1, were published in July 2003. They defined a set of elements that was judged sufficient when they were published. Since then, new needs have appeared, justifying the publication of the version 2008 and those that will follow.
1.2 Objectives
The first recommendations, SupAnn v1, were developed to meet a variety of objectives. The primary objectives are listed below:
- to propose a coherent framework to institutions in order to facilitate the implementation of their respective directories by specifying a common LDAP core;
- to promote software portability in the HEI community by homogenizing the directory schemas in the institutions, thus enabling the native inclusion of the appropriate directory interfaces in the software and avoiding in-depth modifications at a later date;
- to bring together similar internal directory expertise in order to facilitate the work of the directory managers at the operational level and to help increase and improve the potential for exchange between the various stakeholders due to a common language.
It was also necessary to make the institutions aware of the need to implement a master database in order to rationalize their strategy of authentication and access control management; a single master database would guarantee a global vision of the security policy, thus avoiding multiple data captures in different databases, and the risk of incoherency.
Identity federation services that are currently deployed in higher education institutions also bring new constraints to directory schemas as defined by SupAnn recommendations. This type of service is essential for allowing access to digital contents. In fact, identity federation mechanisms rely on authentication delegation and the transfer of user attributes from one higher education institution to another. Within the federation, the format of exchanged user attributes must be the same to allow interoperability, thus pushing new constraints upstream in directory schemas.
It is now necessary to establish common directory schemas throughout the HEI community. In fact, the identity federation function is only possible if the information used by the access control process respects a certain recognized syntax and Semantics. Thus, identity federation is a crucial service for sharing digital resources on the level of the Regional Digital Universities (RDU) and the Thematic Digital Universities (TDU) or accessing digital resources (e.g., electronic journals).
Since the publication of the SupAnn v1 recommendations, most of the institutions have extended their set of applications and services requiring information from the directory. The expectations of these new applications with respect to the directory have continued to diversify. One of the objectives of SupAnn 200x was to integrate data already used by many HEI in their own directory.
The French Higher Education Institutions are requested to implement the changes needed to conform to the orientations presented in this document. However, these recommendations should be considered as the minimum requirements; they can be completed by elements that are specific to each institution. An institution can thus add the elements necessary for its own needs to its directory.
1.3 From SupAnn version 1 to SupAnn 2008
The SupAnn 2008 recommendations were developed to respond to the expectations of the institutions. In fact, the first version of SupAnn, published in July 2003, defined a relatively limited eduPerson superset. The version 2008 introduced a more in-depth examination of the occupational aspects of the HEI, providing definitions of students, staff and structures.
In addition to the new items, the SupAnn technical group also updated, completed and corrected the definitions of certain attributes in SupAnn v1 or defined in eduPerson. In this case, the guidelines encouraged the compatibility between SupAnn v1 and SupAnn 2008. Only a few attributes were rendered obsolete when they were no longer compatible with the values, the Semantics or the use proposed in SupAnn v1. Not used in SupAnn 2008, these attributes were replaced by substantially equivalent attributes (see the list below). The institutions MAY however continue to use the "obsolete" attributes, but they MUST choose new attributes when designing new applications or when exchanging information between institutions.
The changes made in SupAnn 2008 compared to SupAnn v1 are listed below. These changes are likely to require modification of the institutions' directories to insure compatibility with SupAnn 2008.
Obsolete attributes or values
- supannAffectation is replaced by supannEntiteAffectation.
- supannOrganisme is replaced by supannEtablissement.
- supannRole is replaced by supannRoleGenerique.
- the value staff of the attribute eduPersonAffiliation is made obsolete.
New elements
- a new DIT branch for defining the institution's entities (ou=structures)
- a new schema, with
-added classes (organization, dcObject, organizationalUnit, eduOrg, supannOrg, supannEntite)
-new attributes (supannEtablissement, supannCodeEntite, supannCodeEntiteParent, supannTypeEntite)
- a new format for composite attributes (supannEtuInscription, supannRoleEntite)
- new attributes for defining student profiles
(supannEtuAnneeInscription, supannEtuSecteurDisciplinaire, supannEtuDiplome, supannEtuTypeDiplome, supannEtuCursusAnnee, supannEtuEtape, supannEtuElementPedagogique, supannEtuRegimeInscription, supannEtuInscription)
- new attributes for defining assignments
supannEntiteAffectation, eduPersonOrgDN, eduPersonOrgUnitDN, supannEntiteAffectationPrincipale, eduPersonPrimaryOrgUnitDN
- new attributes for defining e-mail addresses (supannMailPerso, mailForwardingAddress)
- new attributes for defining staff profiles (supannRoleGenerique, supannRoleEntite, supannActivite).
Modifications in the use of certain attributes
- update of eduPersonPrincipalName , in which the method for using the attribute is detailed;
- update of eduPersonAffiliation, in which populations and new values (library-walk-in, researcher, retired and emeritus) are defined more precisely, and one value (staff) is made obsolete.
1.4 From SupAnn 2008 to SupAnn 2009
Compatibility
To maintain the coherency of the Semantic interpretations of the values of the attribute eduPersonAffiliation between the different European countries, the SupAnn-tech group rethought the definitions of these values. Some changes were incompatible with the previous definitions, and certain LDAP filters at the application level had to be modified to permit these changes. However, in turn, these changes will greatly facilitate the dialogue with the service providers in the context of identity federations.
Modifications of the existing attributes
- cn: details added to specify that, when dealing with a person's name, the attribute must only contain one value;
- mail: details added to specify that this attribute must only contain one value;
- supannMailPerso: details added to specify that this attribute must not be used to route e-mails;
- mailForwardingAddress: integration of this attribute in the class supannPerson, use of the Fedora Directory Server definition;
- supannActivite: addition of the nomenclature of the SILLAND functions to this attribute;
- supannEtuCursusAnnee: details added to indicate that the value for the year can be omitted if it is unknown;
- eduPersonAffiliation: suppression of the implications related to the value member. Henceforth, this value no longer depends on the person's presence in the institution's databases. A new appendix lists the main staff categories encountered in the institutions and the corresponding attribute values. The value staff is reintroduced and the definitions of faculty and employee are modified so that they are compatible with the other countries using eduPerson. The value teacher is introduced and library-walk-in is deprecated in favor of the new value, registered-reader.
- supannRoleEntite: replacement of the initial elementary attributes supannCodeEntite and supannTypeEntite (from the class supannEntite) by the attributes supannEntiteAffectation and supannTypeEntiteAffectation (introduced in the class supannPerson);
- supannTypeEntite: withdrawn from the class supannPerson (replaced by supannTypeEntiteAffectation)
New attributes
- supannAutreMail (supannPerson): e-mail addresses other than the institutional address contained in mail
- supannEmpCorps (supannPerson): an agent's membership group
- supannTypeEntiteAffectation (supannPerson): the type of entity/structure to which a person is assigned
- supannRefId (supannPerson, supannEntite, supannGroupe): identifiers/links to other IS databases
New labels
- NCORPS for the group nomenclature used by supannEmpCorps
- nomenclature values from extra-higher education organizations can figure in the system, prefixed with the convention <organization name>_<nomenclature type > (e.g., CNRS_CORPS)
New nomenclatures
Nomenclatures using the label{SUPANN} were developed for the attributes supannRoleGenerique, supannTypeEntite and supannRoleEntite and put on-line at
Miscellany
In the attribute descriptions in section 7, information is added about the DIT branch(es) where the attributes appear.
1.5 Process for developing the SupAnn recommendations
Information sources, stakeholders
An institution's directory can be considered as the keystone of its Global Information System (GIS). To all intents and purposes, the directory maintains coherency between all the application bricks in various domains (e.g., authentication, access control). Thus, the format of this directory must respect certain strong inter-operability constraints with respect to syntax, Semantics and stored attribute values.
Various stakeholder categories were consulted about the SupAnn recommendations or contributed directly to their development:
- the RDU and TDU project managers, for the section defining the functional needs;
- the institutions themselves through a subset of their directory managers, for the technical section;
- representatives of the ministries responsible for Information Systems;
- the designers of occupation applications (e.g., AMUE, Consortium Cocktail);
- the DEPP (Office for Evaluation, Prospectives and Performance, which produces statistics for the French Ministry of Education), for the nomenclatures;
- our partners in public scientific or technical institutions (e.g., CNRS, INRIA).
Modification of the recommendations
The institutions that want to submit propositions for new attributes and/or modifications of the existing attributes are requested to contact the supann-tech group at .
Principles guiding the development of the SupAnn recommendations
The development process for the SupAnn 200x recommendations respected a certain number of rules. Some of these rules are listed below:
- insure the greatest possible ascending compatibility with the previous recommendations;
- insure the articulation with international recommendations, especially Internet2/eduPerson or Terena/SCHAC, REFEDs;
- take into account the national nomenclatures (see the section, Nomenclatures);
- ignore needs that are too specific to an institution because each institution has the right to enrich its directory schema to respond to its own needs;
For certain attributes, SupAnn provides the codes (e.g., ”{SISE}2001142” for a degree in social law), but does not provide the element to assign the labels corresponding to these codes. If necessary, the client applications must themselves provide the correspondence code_label, thus offering a flexibility that is appropriate for the local context.
Recommendation requirement levels
This document describes the recommendations and good practices. In order to define the requirement levels needed to respect these recommendations, the terminology used in RFC 2119 is also used here.
The terms and their meanings are listed below, as explained in RFC 2119:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
5. MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product, while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).
1.6 Conformity to legal regulations
A directory contains data about individuals that can often be described as "of a personal nature". All directory managers must insure that the necessary procedures have been undertaken with respect to the French National Committee for Information Technology and Freedom (CNIL ), an independent administrative authority protecting privacy and personal data. They also must insure that the management of the directory conforms to the French Information Technology and Freedom law (Informatique et Libertés). To do this, it is necessary to contact the CIL representative (CIL: Correspondant Informatique et Liberté) at a given institution to obtain the Information Technology and Freedom Guide, published in partnership by the French University Presidents Conference (CPU) and the CNIL.