OCEE documentation
OCEE documentation

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 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:

 

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

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.

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

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.