1. Overview of the Feide LDAP structure

1.1. Terminology

UH-sektoren

Sector covering higher education such as universities.

1.2. Object classes

The demands that Feide puts on the structure on data within the organization’s LDAP-catalogue are based on «norEdu* Object Class Specification». In addition to the specification, this document defines which attributes from norEdu*-specification are mandatory or recommended for organizations within UH-sektoren.

The LDAP-catalogues with the userdata located at each organization are organized into a tree-structure. In this structure lies nodes, which are a collection of attributes and affiliated values about:

• persons

• organizations

• organizational units

norEdu*-specification defined three important object classes:

• norEduPerson

• norEduOrg

• norEduOrgUnit

Each object class defines a set of attributes. Multiple object classes used together can yield a greater set of attributes which comprises all information about a person, organization or organizational unit.

One example for this is that a node with person-information will have attributes from the object classes norEduPerson, schac, eduPerson and inetOrgPerson. inetOrgPerson will use attributes from the object classes person, organizationalPerson and top. Read more about object classes in «norEdu* Object Class Specification».

The two attributes (eduPersonOrgDN and eduPersonOrgUnitDN`) explains which organization and possible organizational units a person is affiliated to. These contains a unique pointer to the nodes within the catalogue-tree that contains information about the organization and organizational units. ``eduPersonPrimaryOrgUnitDN explains which organizational unit the person affiliates to. The unique notes for a person, organization and organizational units, and the interconnections between these are depicted in Figure 1 below.

1.3. Attributes

When a user logs into a service through Feide, the service receives message that the user is authenticated along with a selection of information elements which belongs to this user. The information elements that the service receives are limited through an agreement between Feide and the service. In Feide we use the term attributes about the different information elements.

In general it is recommended to place as much information as possible into the Feide catalogue, and within norEdu*-specification there are attributes for many different types of information elements. Quite a few services requests more and more types of information elements, and the organizations that puts large amounts of information into the Feide-catalogue will more effectively utilize the different services connected to Feide.

In the customer portal the host organizations can view which attributes a service, at any given time, is exposed for. The host organizations have to make sure that a data processing agreement, which regulates the services usage of organizational data, exists between organizations and the service.

To make it easier for the host organizations and the services, Feide has chosen to classify attributes into three categories:

• Mandatory – Shall be placed within the Feide-catalogue

• Recommended – Recommended to be placed within the Feide-catalogue

• Optional – It is up to the organizations itself to evaluate if these should should be placed within the Feide-catalogue.

Mandatory and recommended attributes are often those that the service expects to receive today. In spite of this classification, Feide strongly encourages host organizations to place as much information as possible within the Feide-catalogue. In this document you will find a brief overview of mandatory, recommended and optional attributes.

Figure 1: The different object classes within the Feide-catalogue: person, organization and organizational unit. The arrows shows how distinct attributes within the person-nodes points to the organization and organizational unit(s) the person belongs to. Organizational units are not mandatory in higher education and are therefore lighter in colour.