ESciDoc MPDL LDAP/Single LDAP Server

Single LDAP Server

• A Single eSciDoc LDAP Server will be installed to support the MPDL productive instances of eSciDoc core services and solutions
• Configuration used as described at LocalDirectoryService, see image below

http://www.openldap.org/doc/admin24/config_local.png

The Client in this case is actually the eSciDoc login form.

Configuration with eSciDoc

• see Login configuration for eSciDoc- Part: Login via LDAP server

Design checklist

Directory needs and applications that will use the directory

• Applications that will use MPDL LDAP
  • escidoc-core services (must have)
  • escidoc-based-solutions (must have)
  • CoNE and evtl. other additional services independent of escidoc-core (must have)

• Oranizational structure to be considered for MPDL-based LDAP

• Geographical location: Institutes (sometimes their departments?) are located throughout Germany and several institutes are outside of Germany
• NIMS (Japan): if it stays with current PubMan repository, additional effort of exchange with NIMS LDAP might be needed

• Performance
  • Latency- refers to the elapsed time between when an application makes an LDAP request and when it receives a response.
  • Throughput- refers to the total sustainable operation load that the directory can handle

• Level of service - expected availability 99,98% (according PubMan expected availability)

Data needs

• MPDL-eSciDoc LDAP shall cover the following data:
  • Users (People)
    • username
    • email
    • CoNe Person ID (to clarify if in LDAP or in User attributes of eSciDoc) ?
    • Organization
  • Organizations (Institutes, departments)
    • name, id
    • eSciDoc ID
  • Potentially User Groups
    • user group name
    • user group members

Schema

• Person
  • EduPerson Schema
  • Core attributes to be supported from the EduPerson schema:
    • eduPersonOrgDN-single
      • shall point to the organization class object. The organization object must contain "o" attribute for Organization name.
      • NOTE: if the value of this attribute should be resolved via OU level privileges in eSciDoc, then the value must be the id of the organizational unit in eSciDoc. However, there can be another attribute that holds the value of the escidoc id. This is to be configured in the escidoc-core.properties file for escidoc-core deployment.
    • cn-Common Name, multivalued
      • the Common name (usually the full name of the user). There can be several values, recommended a single value
      • todo: check if multivalues are needed in case of e.g. another script (Japanese)
    • sn-Surname, multivalued
      • the surname of the user. Recommended multiple values if user surname has several components to get best search results.

• • other attributes to be supported
    • eduPersonOrgUnitDN
      • motivation: evtl. user groups based on departments or organizational units
      • should point to the organization class object. In this case, "o" attribute is not required, but "ou" attribute (e.g. name of the department) is required
    • eduPersonPrincipalName
      • motivation: evtl. further implementation of Shibboleth, defines the scope of the user between institutions
      • form: user-name@scope

• Organization
  • EduPerson Schema

• • • Cn (common name),
    • sn (surname, family name)
    • o (name of the organization)

• Design your schema
• Design your namespace
• Design the topology of your directory
• Design your directory replication scheme
• Design your directory for security and privacy

Lightweight Directory Access Protocol

Enhanced Scientific Documentation

Max Planck Digital Library

Control of Named Entities

National Institute for Materials Science Japan

Publication Management

Identifier

Organizational Unit

Logging-in system for computer networks