LDAP Connector
This page provides a short description of LDAP and an overview of the functions of the OCEE LDAP Connector. The primary purpose of the LDAP connector is to map pre-existing users and groups in an external LDAP directory to OpenCms users and groups for the purpose of authentication. Creation of the users and groups in the LDAP directory is outside the scope of the LDAP connector.
LDAP
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.
dc=my-domain,dc=com
ou=Applications
ou=OpenCms
cn=Administrators
uid=Admin
cn=Projectmanagers
cn=Users
cn=Guests
uid=Guest
uid=Export
ou=People
uid=TestUser
ou=Groups
uid=TestGroup
LDAP entities and attributes
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:
dn: uid=TestUser,ou=People,dc=my-domain,dc=com
uid: TestUser
description: A test user
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Firstname
givenName: Lastname
cn: Firstname Lastname
mail: firstname.lastname@my-domain.com
userPassword: e1NIQX1xVXFQNWN5eG02WWNUQWh6MDVIcGg1Z3Z1OU09
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.
dn: cn=Guests,ou=OpenCms,ou=Applications,dc=my-domain,dc=com
cn: Guests
description: OpenCms Guests
objectClass: top
objectClass: groupofuniquenames
uniqueMember: uid=Guest,cn=Guests,ou=OpenCms,ou=Applications,dc=my-domain,dc=com
uniqueMember: uid=Export,cn=Guests,ou=OpenCms,ou=Applications,dc=my-domain,dc=com
Supported standard user and group entity schemas
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)
- Group Entities: The following standard group entities are supported:
- groupOfUniquenames (RFC2256)
- groupOfNames (RFC2256)
- posixGroup (RFC2307)
- groupOfUrls
How the LDAP Connector works
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.
Password handling
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.