This section explains the main design issues behind the LDAP Utils. LDAP is a complex protocol, and albeit being widely used there's not a de facto standard. As such, when designing an API to encapsulate LDAP operations some options had to be made.
Different LDAP technologies use distinct representations for users and groups. Those entities have different structures and are composed by distinct attributes. In order to be able to provide implementations compatible with different underlying technologies a normalization effort must be made. As such, the structure of users and groups of several LDAP technologies was analyzed and a common model was derived.
Two data types that mimic users and groups on an LDAP server were modeled: LDAPUser and LDAPGroup. These two act as data transfer objects between the LDAP server and the client application. They also define some attribute names common to several LDAP technologies. Both classes inherit from a base class, LDAPEntity, that defines attributes common to both LDAPUser and LDAPGroup. In fact, every entity on an LDAP server must have attributes such as the distinguishedName, the cn (common name) and the name. Those are the kind of attributes that were placed on the top class. All classes are regular POJOs with private members and getters and setters for member access.
Check the LDAPEntity, LDAPUser and LDAPGroup javadocs for more information.
A consequence of the previous section is that different LDAP technologies will use different attribute names. This situation might cause an impact on design since it might interfere with code reusage. To solve this issue all the attributes whose names are not shared among LDAP technologies were moved to AbstractLDAPUtils. Since this must be subclassed for different technologies the specific attribute names are defined on the subclasses.
The AbstractLDAPUtils is a base class that offers standard implementations for most of the LDAP operations. This implementation must be extended for the different technologies. These extensions might reuse the code provided by AbstractLDAPUtils or define new ones.
Check the AbstractLDAPUtils x-ray and the new implementations pages for more information on these issues.
| Note: The following only applies to AD implementation. |
To provide a convenient abstraction for LDAP operations the user must not be hooked to technical issues, such as using the distinguishedName to access the entities or even having to calculate it's value upon entity addition. A more user-friendly approach was derived based on user's login name and the group's common name. These two attributes were chosen since they present an easier identifier for the user to remember that the distinguishedName with it's awkward syntax. To achieve this flexibility an entity is placed on the same level as it's "parent group" (the following section will address this concept).
Under the hood this is reflected on the distinguishedName evaluation. The entity's distinguishedName is calculated from the parent group one. As a side effect, this causes independence of the LDAP server layout as only the "last" group matters. Also the user is abstracted from the clumsy distinguishedName syntax, having just to deal with the much simpler login names and common names.
The parent group concept is tightly related with the previous section. But it has also a broader scope. The parent group, on an LDAP tree perspective, is the location where the entity is placed upon creation. It can also be thought of as a role identifier. Sometimes, a user can belong to several groups, but one of those will be dominant over the others. The parent group will solve this requirement.