ESciDoc MPDL LDAP

Introduction

• A concept to implement LDAP with the eSciDoc solutions at MPDL
• see MPG Authentication and Authorization Infrastructure
• see LDAP@Wikipedia
• see Understanding LDAP
• see On eSciDoc Security
• see On Supported eSciDoc authentication mechanisms (valid up to version core-service v.1.2)
• see LDAP Tutorial

Requirements

• eSciDoc services and solutions should authenticate their users via external mechanism
• grants and privileges are still stored with eSciDoc core service
• would be good to be able to create some groups and group-based privileges in eSciDoc based on Identity provider groups or values of some attributes sent via LDAP/Shibboleth
• Institute level-user administrators should be able to manage their user accounts
• It should be possible to use LDAP to define user groups and use these user groups to create grants for eSciDoc repository resources
• Future scenarios (without Shibboleth):
  • No Shibboleth scenario: MPDL LDAP server to be consumer of LDAP accounts from local institute LDAP server (authorized)
  • Shibboleth scenario: Shibboleth federation within the overall MPG AAI

Possibilities with eSciDoc

• eSciDoc allows for three types of authentication mechanisms of users
  • local authentication
  • LDAP based authentication
  • Shibboleth based authentication

Local authentication (deprecated)

Within the local authentication mechanism, all user accounts are stored with the eSciDoc internal local user database. Besides the user accounts, the local user database additionally stores information on user groups, available authorization policies, user roles (based on these authorization policies) as well as grants of roles to users and user groups for eSciDoc resources.

Note: at present the eSciDoc solutions and services deployed at MPDL are using local authentication mechanism. Further development of the local authentication mechanisms is deprecated since core-service v1.2. The mechanism will be enabled for quick testing, however will not be further extended or developed.

• For each user account, the following information is stored:
  • username(defined during the creation of the user)
  • user-id (internally assigned by the system)
  • email
  • optionally more user attributes may be added to the user such as: reference to the organizational unit to which user belongs etc.

For more details, see see On Supported eSciDoc authentication mechanisms, part Login via internal Account resource (deprecated)

Authentication via LDAP

Authentication via LDAP requires that the user accounts are stored with the LDAP database. During the user-login the LDAP database is searched for existence of the user account and authentication rather than escidoc local database. The principle in general is similar. eSciDoc treats LDAP attributes in the following manner:

• UserAccount.loginname:To assure unique login names in case of using multiple LDAP servers (which should possible but currently has not been tested), the LDAP username (e.g. uid) and the distinguished name (dn) of the user are concatenated and "tokenized". E.g., if the user is identified by entering "foo" as the user name and the LDAP server returns the distinguished name "cn=foo bar, ou=example, ou=org", the resulting internal loginname would be "foo,cn=foo_bar,ou=example,ou=org".
• UserAccount.name: The first part of the distinguished name (e.g. "foo bar" in the example above) is used as the name of the UserAccount.
• From framework-version 1.2 on: All the other LDAP attributes of the user and the names of the LDAP groups the user belongs to are written as user-attributes into the internal eSciDoc-Database. If there are LDAP groups created, then the user-attribute-name for the LDAP-groups the user belongs to is 'groupRole'.

For more details see see On Supported eSciDoc authentication mechanisms, part Login via LDAP server

Authentication via Shibboleth

• see On Shibboleth
• see On setting-up Shibboleth for wSciDoc

Shibboleth is a federation based distributed authentication system. A federation consists of service providers (SPs) and identity providers (IDPs). The first provides resources secured by shibboleth, the latter provides the login and authentication of the providers and exposes the user's attributes to the service providers.

In eSciDoc, there exists one "user entry point", the login servlet, that encapsulates the details of the used authentication mechanisms. During login, a user accesses this servlet and is authenticated by one of the authentication mechanism. After successful authentication, the servlet generates an eSciDoc user handle that will be used to authenticate the user to the eSciDoc infrastructure services.

Attributes sent to eSciDoc via Shibboleth are stored automatically as user attributes with each user log-in. For more details see see On Supported eSciDoc authentication mechanisms, part Login via Shibboleth

Options for MPDL

• Local authentication and authorization (done, not sufficient)
• LDAP-based authentication (decided)
• Shibboleth-based authentication (leave for future scenarios - together with MPG AAI implementation)

Roadmap for LDAP-based authentication

• Stage I (schedule: asap) : install single LDAP Server, install Web interface to the LDAP Server
• Stage II(schedule: not clear) : exchange data with institute's LDAP servers

Lightweight Directory Access Protocol

Enhanced Scientific Documentation

Max Planck Digital Library

Logging-in system for computer networks

Max-Planck-Gesellschaft

Authentication, Authorization and Identification