The final component of the services management system is responsible for the instantiation of the service on a server and is known by its acronym UAMS. This sub-system is responsible for serving as the bridge between the USDB and the actual servers providing end-user services.
An important concept in this services oriented solution is the notion of 'binding' a particular service entity to a host. A service entity is most easily understood to be a user with a specific service such as electronic mail. The USDB application layer provides a mechanism where a number of hosts can be defined as candidates for providing a particular service and then placed into a pool. At the time of service creation the binding process selects a candidate server using either a round-robin or weighted averages algorithm and 'binds' the user to that server. The UAMS layer is responsible for taking this binding request from the USDB and carrying out the actions needed to prepare the server to provide the service for the user.
The USDB application layer also supports the notion of so called ``hostless'' services. These are services which only require KerDAP API services and do not actually require account creation on the server. Two examples of such services are USENET news service and authenticated WEB proxy service. In both cases the kerdauth binary is used to provide simple authentication and authorization services via the external authenticator mechanism provided by INND and the Squid proxy server. The only action needed to instantiate the service is the presence of the user in the LDAP directory with an appropriate services tag and a Kerberos principal for authentication.
The UAMS system is designed around the paradigm of queueing requests for user services. Queued requests are stored in separate spooling areas, one for each server. The system provides for locking and arbitration of access to the queue. Requests for service instantiation are stored until the queue is ``processed'' either by an administrator or by an automated mechanism. Processing of the requests can be carried out either on a per host basis or globally for all hosts which have entries in their request queue. The process of ``running'' a queue involves reading each request and sending that request via an authenticated and encrypted session to the target host. The results of the requests (success or failure) are appended to the service request and are used to replace the request queue. This mechanism provides for historical accounting of the success or failure of the requests. The UAMS system provides tools for an administrator to review both pending and processed requests.
The actual syntax of the service request are very simplistic. The following tables contain the input for a series of pending requests and the resulting output:
| imap1.domain:Bull_Dozer:EMAIL:create |
| imsp1.domain:Bull_Dozer:CONFIG:create |
| kdc1.domain:Bull_Dozer:KERBEROS:create |
| imap1.domain:Back_Hoe:EMAIL:delete |
| imap2.domain:Road_Grader:EMAIL:modify:quota |
| imap1.domain:Bull_Dozer:EMAIL:create:OK |
| imap1.domain:Bull_Dozer:CONFIG:create:OK |
| imap1.domain:Bull_Dozer:KERBEROS:create:FAILED |
| imap1.domain:Back_Hoe:EMAIL:delete:OK |
| imap2.domain:Road_Grader:EMAIL:modify:quota:OK |
The actual instantiation of the services is carried out by UAMS clients which are installed on the target hosts. The entire UAMS system is implemented with Bourne Shell scripts and relies on the notion of function inheritance to implement the actual service classes.
The basic UAMS client implements a library of common functionality including user account creation via the useradd utility. Each service category is implemented by sourcing in a module which has the option of either replacing existing functions with modified versions or using the functionality provided by the base library. This inheritance mechanism also provides the ability to import functionality from host and domain specific service modules. This system allows modules to be written which support enterprises with the need for tailoring services on the basis of organizational unit needs. While the UAMS client itself is implemented in Bourne shell the actual service instantiation modules can include any tools and/or languages available on the target platform. Pre- and post-processing hooks are also implemented to handle any setup or departure requirements needed for a sequence of service management requests.
Within this middleware solution the LDAP directory is defined as the official API for obtaining any and all information relevant to the implementation and delivery of services. This requirement enables the simplistic UAMS syntax. The UAMS client library provides a number of convenience functions for interrogating the LDAP directory and returning data attributes needed to implement the service instantiation process. This requirement has a number of implications: first of all, LAMS and UAMS invocations must be synchronized to insure that service creation occurs after the meta-directory system has populated or updated the LDAP directory servers. The second implication is that this requirement imparts an additional degree of security since an intruder would need to compromise the directory servers in order to effectively coerce the system into creating invalid or modified accounts.