Work in progress
This site is in the process of being reviewed and updated.
Introduction
This page describes the way the Normalizer Interceptor is implemented.
The normalizer interceptor tasks is to transform the DN and Attributes to fit with what the server is able to manipulate. Basically, the following operations are handled :
- DN normalization
- Attribute transformation to use the OIDs of each AttributeType instead of a name
- Attribute values normalization using the normalizer associated with their type
- Deletion of duplicted values after these normalization
Initialization
We need to initialize some structures to be able to handle those transformations :
- AttributeTypeRegistry : this structure contains an association between each attributeType and all the related information (OID, aliases, matching rules, normalizers, etc ...)
- NormalizingVisitor : ???
- ExpandingVisitor : ???
Operations
This interceptor implements some of the operations defined in its interface :
Interface |
SchemaService |
|---|---|
add |
|
addContextPartition |
|
bind |
|
compare |
|
delete |
|
destroy |
|
getMatchedName |
|
getRootDSE |
|
getSuffix |
|
hasEntry |
|
init |
|
Interface |
SchemaService |
|---|---|
isSuffix |
|
list |
|
listSuffixes |
|
lookup |
|
modify |
|
modifyRn |
|
move |
|
removeContextPartition |
|
search |
|
unbind |
|
Add operation
An add operation contains the entry DN and all the attributes to be added. We must normalize the DN, and then check the attributes.
Some of those controls are done in the SchemaService Interceptor, like the presence of mandatory attributes, but here, we must transform the attributes to replace attributeTypes by their OID counterPart, and by normalizing each value to see if some of them are duplicated. We will clone the attributes and it will be used by all the other interceptors for all the implemented controls. However, we keep the original entry to store it into the backend.
Ideally, the backend should store the original entry and the normalized entry, so that we can return to the user the original value only.
This leads to a huge modification in the backend, because we will have to store not only the entry, but also the normalized entry, doubling the backend size. We can improve this by modifying the Attribute(s)Impl object, with a structure where values are not duplicated if the user provided value equals the normalized value (this is often the case, and always if the attribute is binary).
Bind operation
The Bind operation just contains a DN which is the name of the user who want to bind. We will only have to normalize this DN. The DN is received in a form which is already partially normalized by the LdapDN internal parser, but we didn't applied yet the transformation associated with the attributeTypes of each RDN. This is what we will do in this operation.