Directory Manager

The Directory Manager configuration consists of an XML file and an index file. The index file is actually an instance of no.feide.moria.directory.index.SerializableIndex written to file (using the tool no.feide.moria.directory.index.tools.SerializableIndexCreator, described in detail in the Directory Manager module description, which is in turn referenced from the Directory Manager configuration XML file.

Two implementations of the Directory Manager backend exists; a JNDI backend, for accessing authentication servers (usually plain old LDAP servers) through JNDI, and a dummy backend, which can be configured to emulate one or more functioning authentication servers.

Both backend implementations' configuration file contain one root DirectoryManagerConfiguration element. This in turn contains two child elements; the Index element and the Backend element.

The Index element only has two attributes - file, giving the filename (absolute or relative path) of the previously mentioned SerializableIndex file, and update, which is the index update interval in seconds. The update will only occur if the timestamp of the index file has changed.

The Backend element differs between backend implementations, but will always include one attribute, class, which states which backend implementation to use. Legal values are no.feide.moria.directory.backend.DummyBackendFactory and no.feide.moria.directory.backend.JNDIBackendFactory. The children of the Backend element varies depending on the implementation given by the class attribute.

Dummy Backend

For the dummy backend, the Backend element must contain one Dummy child element. The Dummy element may contain one or more User child elements, with the attributes name (for the user's username) and password (for the user's password). The User element may contain one or more Attribute child elements, with the attribute name (for the attribute's name). The Attribute element must contain one or more Value child elements. The Value element must contain a text child element with an attribute value.

Thus for the dummy backend it is possible to configure several users (with passwords) with several attributes that in turn may yield several values.

An example Directory Manager configuration file using the dummy backend: 

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<DirectoryManagerConfiguration>
    <Index file="src/test/conf/DummyIndex.object"
           update="120"/>
        <Backend class="no.feide.moria.directory.backend.DummyBackendFactory">
            <Dummy>
                <User name="user@some.realm"
                      password="password">
                    <Attribute name="MyAttribute">
                        <Value>MyValue</Value>
                    </Attribute>
                </User>
            </Dummy>
        </Backend>
</DirectoryManagerConfiguration>

In this example we have configured one user, with a single-valued attribute MyAttribute.

JNDI Backend

For the JNDI backend, the Backend element must contain one JNDI child element, with the attributes timeout (giving the timeout, in seconds, used when accessing authentication servers), usernameAttribute (used when trying to match a username to a given user), and guessedAttribute (used for guessing on the user Distinguished Name when searching fails). The JNDI element must contain one Security child element. The Security element must contain one Truststore child element, with the attributes filename (relative or absolute, to the file containing the truststore with authentication server or CA certificates), and password (to the truststore).

Thus for the JNDI backend it is possible to configure how to access and search for users on an authentication server, and how to authenticate the authentication server itself.

An example Directory Manager configuration file using the JNDI backend: 

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<DirectoryManagerConfiguration>
    <Index file="src/test/conf/TestIndex.object"
           update="120"/>
    <Backend class="no.feide.moria.directory.backend.JNDIBackendFactory">
        <JNDI timeout="10"
              usernameAttribute="eduPersonPrincipalName"
              guessedAttribute="uid">
            <Security>
                <Truststore filename="src/test/conf/moria.truststore"
                            password="changeit"/>
            </Security>
        </JNDI>
    </Backend>
</DirectoryManagerConfiguration>

Index

The index configuration file, used to generate the actual index file, consists of a root Index element. The Index element may contain one or more Associations and/or Exceptions children.

The Associations element contains one or more Realm children, each with an attribute name giving the logical realm name for the user's falling into this realm. This assumes usernames on the form identity@realm, where the realm's name attribute is the latter part. Each Realm element may contain one or more Base children. Each Base has the attributes name, giving a potential LDAP search base for this realm, as well as the two optional attributes username and password. These latter two, if specified, are to be used when searching for the user elements's actual DN in case the LDAP server does not allow anonymous searching.

The Exceptions elements contain no children, but the attributes id, giving the full username (which may not be on the form identity@realm) of a user; reference, giving the full reference to the user element; and realm, giving the actual realm the user belongs to - this allows for users to retain the usernames even when moving between organizations (each with its own realm).

Together, Associations map a group of users to one or more search bases based on their realm membership, while Exceptions give a one-to-one mapping between usernames and search bases.

An example index configuration file is shown below: 

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>

<-- 

A sample index file, with two associations for the same realm and one exception.
This file is used to create and write a SerializableIndex object to file, using
tools such as no.feide.moria.directory.index.tools.SerializableIndexCreator.

More than one base ("implicit reference") may be associated with the same realm,
but only one reference ("explicit reference") may be associated with any given
user ID.

-->

<Index>

    <!--
	     Associate the realm some.realm with two different search bases, using SSL (port 636).
	     The last base requires a username/password to perform initial bind for user DN searching.
    -->
 	<Associations>
		<Realm name="some.realm">
			<Base name="ldap://some.ldap.server:636/ou=users,dc=some,dc=where"/>
			<Base name="ldap://some.ldap.server:636/ou=people,dc=some,dc=where" username="access" password="please"/>			
  		</Realm>
	</Associations>  		
	
    <!--
	     Associate the user ID with one user element reference, using SSL (port 636).
	     This will override the above association. The "realm" attribute is used to
	     tie the user to a given organization, for authorization purposes.
    -->	
	<Exception id="user@some.realm" reference="ldap://another.ldap.server:636/uid=user,ou=people,dc=another,dc=place" realm="some.realm"/>	
	
</Index>

The tool used to generate the index object based on such a file is given in the class SerializableIndexCreator.