 | Work in progress This site is in the process of being reviewed and updated. |
Introduction
Apache DS has to keep a lot of internal structures available from all the parts of the server. This is done through what we call Registries. We have many kind of Registries :
- OID Registry : it stores a relation between object names and the associated OID.
- ObjectClass Registry : it stores all information related to ObjectClasses
- Syntax Registry : it stores all thye syntax checkers.
- <to be continued>
A very important point is that all those registries are just objects used to ease the navigation through the different elements tha server is using. The central point is the OID object.
If we focus on ObjectClass and AttributeType, then we will need to use this hierarchy :
AttributeType hierarchy
The AttributeType classHierarchy is shown in the following picture :
|
We don't represent the existing hierarchy, which includes some more classes, separated in an AbstractAttributeType class and 4 implementation, into Producer classes, because I don't think it fits the need. We should just have one concrete implementation, and no abstract classes, as we will not extend the AttributeTypes in any way. Those classes will be removed :
|
ObjectClass Hierarchy
The ObjectClass hierarchy is pretty much the same, with some different attributes.
Syntax object
The syntx object is used to check that attributes are correctly formatted when submitted by a user. For instance, the Bit String syntax is '00101...(0|1)...1011'B* and we must check that the given attribute value respect this syntax. The RFC 4517 list 34 different syntaxes to be implemented.
Here is the hierarchy for this kind of object :
The isActive method is used to tell if the syntax is available, or not : if we want to be RFC 2252
compliant, some syntaxes won't be available.
We can see that we may have many syntax checkers. The list are given in RFC 2252, RFC 4517 and RFC 4523:
| RFC 2252/22566 | RFC 4517/4523 | Syntax Checker | OID | H/R |
|---|---|---|---|---|
| X | X | Attribute Type Description | 1.3.6.1.4.1.1466.115.121.1.3 | Y |
| X | (removed) | Binary | 1.3.6.1.4.1.1466.115.121.1.5 | N |
| X | X | Bit String | 1.3.6.1.4.1.1466.115.121.1.6 | Y |
| X | X | Boolean | 1.3.6.1.4.1.1466.115.121.1.7 | Y |
| X | (RFC 4523) | Certificate | 1.3.6.1.4.1.1466.115.121.1.8 | N |
| X | (RFC 4523) | Certificate List | 1.3.6.1.4.1.1466.115.121.1.9 | N |
| X | (RFC 4523) | Certificate Pair | 1.3.6.1.4.1.1466.115.121.1.10 | N |
| X | X | Country String | 1.3.6.1.4.1.1466.115.121.1.11 | Y |
| X | X | Delivery Method | 1.3.6.1.4.1.1466.115.121.1.14 | Y |
| X | X | Directory String | 1.3.6.1.4.1.1466.115.121.1.15 | Y |
| X | X | DIT Content Rule Description | 1.3.6.1.4.1.1466.115.121.1.16 | Y |
| X | X | DIT Structure Rule Description | 1.3.6.1.4.1.1466.115.121.1.17 | Y |
| X | X | DN | 1.3.6.1.4.1.1466.115.121.1.12 | Y |
| X | X | Enhanced Guide | 1.3.6.1.4.1.1466.115.121.1.21 | Y |
| X | X | Facsimile Telephone Number | 1.3.6.1.4.1.1466.115.121.1.22 | Y |
| X | X | Fax | 1.3.6.1.4.1.1466.115.121.1.23 | N |
| X | X | Generalized Time | 1.3.6.1.4.1.1466.115.121.1.24 | Y |
| X | X | Guide | 1.3.6.1.4.1.1466.115.121.1.25 | Y |
| X | X | IA5 String | 1.3.6.1.4.1.1466.115.121.1.26 | Y |
| X | X | Integer | 1.3.6.1.4.1.1466.115.121.1.27 | Y |
| X | X | JPEG | 1.3.6.1.4.1.1466.115.121.1.28 | N |
| X | X | LDAP Syntax Description | 1.3.6.1.4.1.1466.115.121.1.54 | Y |
| X | X | Matching Rule Description | 1.3.6.1.4.1.1466.115.121.1.30 | Y |
| X | X | Matching Rule Use Description | 1.3.6.1.4.1.1466.115.121.1.31 | Y |
| X | (removed) | MHS OR Address | 1.3.6.1.4.1.1466.115.121.1.33 | Y |
| X | X | Name and Optional UID | 1.3.6.1.4.1.1466.115.121.1.34 | Y |
| X | X | Name Form Description | 1.3.6.1.4.1.1466.115.121.1.35 | Y |
| X | X | Numeric String | 1.3.6.1.4.1.1466.115.121.1.36 | Y |
| X | X | Object Class Description | 1.3.6.1.4.1.1466.115.121.1.37 | Y |
| X | X | Octet String | 1.3.6.1.4.1.1466.115.121.1.40 | Y |
| X | X | OID | 1.3.6.1.4.1.1466.115.121.1.38 | Y |
| X | X | Other Mailbox | 1.3.6.1.4.1.1466.115.121.1.39 | Y |
| X | X | Postal Address | 1.3.6.1.4.1.1466.115.121.1.41 | Y |
| X | (removed) | Presentation Address | 1.3.6.1.4.1.1466.115.121.1.43 | Y |
| X | X | Printable String | 1.3.6.1.4.1.1466.115.121.1.44 | Y |
| - | X | Substring Assertion | 1.3.6.1.4.1.1466.115.121.1.58 | Y |
| X | (RFC 4523) | Supported Algorithm | 1.3.6.1.4.1.1466.115.121.1.49 | N |
| X | X | Telephone Number | 1.3.6.1.4.1.1466.115.121.1.50 | Y |
| X | X | Teletex Terminal Identifier | 1.3.6.1.4.1.1466.115.121.1.51 | Y |
| X | X | Telex Number | 1.3.6.1.4.1.1466.115.121.1.52 | Y |
| X | X | UTC Time | 1.3.6.1.4.1.1466.115.121.1.53 | Y |
As we can see, each syntx should have a specific class associated with a specific check method used to control that the attribute value is correct. This value will be checked for every entry adsded or modified by a user. Each DN submitted will also be checked against those classes.
To be able to extend the server with new syntaxes, thoses checker classes will be dynamically loaded at startup. We can do that in different ways :
- defining those classes into ADS code, and load them statically during the compilation of the server : this will not be dynamic, but anyway, we will follow the specification and the server will be LDAP V3 compliant
- using the configuration file and declare all those classes as spring beans, loaded from a jar.
- compiling the syntaxChecker classes and injecting the .class into the cn=schema,ou=system partition : this would be the best solution, except that we need to add some tooling to create new checkers.
.