LDAP Connector

LDAP is an internet protocol for accessing and updating information organized in directories. Here, a directory is a listing of information about objects arranged in some order that gives details about each object. Such directories are managed by directory servers and can be accessed using the Lightweight Directory Access Protocol. For example,

ldap://<ldapserver>/ou=people,o=alkacon.com??sub?(cn=Test User)

would be an URI to access information from the object with an attribute cn and the value “Test
User”, located somewhere in the sub tree below an object with attribute/value ou=people that is below an object with attribute/value o=alkacon.com.

Compared to a usual file system, note the following aspects:

• The data is organized hierarchically, but there is no difference between files and folders; all nodes are objects containing attributes and (multiple) values according to object specifications called schemas.
• The “path” to the object is build from right-to-left; this means the root node is the rightmost part. So, in ou=people,o=alkacon.com the node with o=alkacon.com is the root of the object hierarchy.
• In order to obtain an overview of conceptual and technical aspects of LDAP, see the following
  documents:
  • LDAP Wikipedia entry - https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
  • The JNDI Tutorial - https://docs.oracle.com/javase/tutorial/jndi/index.html
  • OpenLDAP, open source LDAP implementation - http://www.openldap.org

Besides any LDAP entities used to build a hierarchical structure within the LDAP server, the OpenCms LDAP driver expects data objects to specify a single user and to specify a single group, including the membership information. Typically, these objects are based on standard LDAP object classes, where the exact data mapping can be modified by changing the configuration options for data mapping.

Since the starting points for user and group lookups can be specified in the configuration options, the OpenCms LDAP driver does not expect any specific organization of the LDAP entities. Especially, for both user and group lookups, more than one starting point can be specified. As an example, here is an outline of the hierarchical organization of the LDAP example data. The user and group entities are separated into various structures: users and groups needed by OpenCms are located below

ou=OpenCms,ou=Applications,dc=my-domain,dc=com and non-system users

and groups are located below

ou=People,dc=my-domain,dc=com and ou=Groups,dc=my-domain,dc=com

respectively.

This section gives an overview of LDAP attributes used within OpenCms as default setting.
These attributes are part of standard object class specifications, which require other attributes
that must be specified within the LDAP server, too. The mapping and usage of this attributes
can be configured very flexible by setting the appropriate configuration options.

User entities typically have the format shown below:

The Alkacon OCEE LDAP Connector supports several standard user and group entity
schemas, as described in the next section.

Group entities typically have the following format. Please note that group membership is defined
explicitly by the member attributes, not by the entity hierarchy in the LDAP server.

The Alkacon OCEE LDAP Connector feature supports several standard user and group entity
schemas.

• User Entities: The following standard user entities are supported:
  
  • inetOrgPerson (RFC2798)
  Technically speaking any attribute mapping is supported, and since no group membership information is included in the user entity, almost every user entity is supported by OpenCms.
• Group Entities: The following standard group entities are supported:
  • groupOfUniquenames (RFC2256)
  • groupOfNames (RFC2256)
  • posixGroup (RFC2307)
  • groupOfUrls
  As with user entities, any attribute mapping is supported. But the issue with group entities is the definition of the membership information, in that sense, supported group entities are all those having a list of members, where each member is described by a full DN (groupOfNames and groupOfUniquenames), by a user id (posixGroup) or by a search URL (groupOfUrls).

The LDAP connector is a (mostly) read-only implementation that maps user and group entities from a
LDAP server into the local OpenCms database. The only write operations to the LDAP server supported by the LDAP connector are to change the password of a user, and to write some user attributes back to the user.

There is a default user group, called by default (configurable) “LDAP Group” of which all LDAP users are a member. It is not possible to manually add or remove users to this group. This group is useful to have fast overview and access to all LDAP users. So, you can use this group to set permissions or whatever, that will affect all LDAP users.

There are some important points to know about how the user password is handled by
OpenCms. First of all, during the login process, the user is directly authenticated with the LDAP Server, this means the password is sent in plain text. If the authentication is successful an encrypted version of the password, digested by maybe another algorithm, will be stored in the OpenCms database.

If you change a password of a LDAP user, the password is sent to the LDAP server in following
format:

{digestType}encodedPwd

That is something like:

{SHA}X03MO1qnZdYdgyfeuILPmQ==

Unless you set the digest type to plain, in that case the plain password is sent.