Introduction
There is two ways to initialize the server :
- As a standelone server
- As an embeded server
Both initialization are different, for the user perspective, but not from the developper perspective, as the first initializtion system embed the server, just adding some specific mechanism to stop the server (remember that the server can be launched as a daemon)
The server initialization is done in two steps. The first one read the confuguration, and set all the necessary structures, and the second step start the server.
Initialization
This is done by reading the server.xml file, which is a Spring based document. As we refer many classes into this file, they will be instanciated on the fly.
The following classes are created :
Object |
Class |
Description |
|---|---|---|
environment |
HashTable |
Initialize the euthentication objects for Ldap, Kerberos, Naming, ChangePW, and set of binary attributes |
configuration |
MutableServerStartupConfiguration |
Initialize the server |
systemPartitionConfiguration |
MutableBTreePartitionConfiguration |
Configuration of the system partition |
examplePartitionConfiguration |
MutableBTreePartitionConfiguration |
Configuration of an example partition |
The following schema represent the properties set by this configuration file :
During this phase, we instanciate the MutableServerStartupConfiguration, which will initialize a lot of structures, through the call to those three methods :
- setDefaultAuthenticatorConfigurations
- setDefaultBootstrapSchemas
- setDefaultInterceptorConfigurations
setDefaultAuthenticatorConfigurations
This method initialize the authentication methods. At the moment, we support only Simple authentication (ie with a password) or Anonymous authentication.
Each authenticator is stored in a MutableAuthenticatorConfiguration object, which associate a name and a dedicated class.
Should those authenticator be plugins ?
We could declare those authenticator as plugins into the server.xml file, allowing us to easily add some new authenticator. However, this will introduce some weakness in the security system. If somebody add a faked authentication class, and modify the configuration file to load this plugin, what could happen?
SASL
SASL authentication should still be implemented...
For information about authentication mechanisms, open this page : Authentication Mechanisms in ADS
setDefaultBootstrapSchemas
In this method, we will load all the default schemas, which are :
- CoreSchema
- CosineSchema
- ApacheSchema
- InetorgpersonSchema
- JavaSchema
- SystemSchema
- CollectiveSchema
Those schema are transofmed into classes by a maven plugin, and they initiate all the needed structures to handle Ldap ObjectClass, Attributes, Comparator, MatchingRules, etc...
The description of this setup can be found in this page : Schema loading
It can be noted that at thsis stage, we don't load any other schema. Users defined schema are loaded after the initialization of the server has been done.