|
By Schlomo Schapiro
Hebrew University of Jerusalem huji at schlomo dot schapiro dot org |
LDAP = Lightweight Directory Access Protocol. A protocol to access a hierarchical database ("Directory") over TCP/IP. The Directory has to comply with a certain standard regarding how it is organized, what kind of data structures exist, how certain standard entities are called (e.g. User ...) and many more details. This leads to a standardized access method to Directories and a standardized syntax for accessing user information that is independent of the specific implementation of the Directory Server.
In a Directory the data is organized hierarchically similar to a file-system. Under a single root object there can be either container objects (similar to directories) or leaf objects (like files). All objects carry information in the form of attribute-value pairs with many different types of values (strings, numbers, multiple strings/numbers, addresses, links to other objects etc.). The structure of the objects (e.g. what attributes of what type they possess) is called the Schema of the Directory, a hierarchical tree of definitions.
Some object types and attributes are standard and mandatory (by the LDAP spec): User, Organization, Country, Organizational Unit and Common Name, Access Control Lists, Object ID, Locality etc. In addition to the pre-defined objects and attributes one can define an unlimited variety of objects and attributes or extend existing objects by new attributes. These are called Schema Extensions. With the help of such extensions it is possible to map almost any data structure for any need into the Directory, like Workstations, Doors, Campuses, Cars ...
The hierarchical structure of the Directory allows for inheritance in many cases: ACLs are inherited from the parent object (unless the Inheritance Filter is used), the schema of an object can be inherited from another object and then extended (e.g. to make a custom user object). Many applications make use of the hierarchical structure to assign features via a parent object (e.g: Allow all users in a container to print by allowing the container to print), though this is a feature of the application and not the Directory itself.
LDAP provides user-level security and encrypted access. A client has to authenticate itself via a User object and only then it can access data (read/write attributes of objects, manipulate objects ...) in the Directory according to its rights as defined via the ACLs. The LDAP server enforces this security and the ACLs, meaning that it is a closed system where the data and it's access rights are kept together. For anonymous access a Public User is predefined and can be assigned ACLs.
In general an LDAP server only stores information and does not process it as opposed to a relational database or an application server. All data processing has to be done outside of the LDAP server, usually in the client or middle-ware between the LDAP server and the user. This means that an LDAP server can not store dynamical data (e.g. data which should look different each time it is requested, like OTPs or the current time) or pre- or postprocess the data. The advantage of this is that LDAP servers are exchangeable easily since they provide only data storage and do not contain any application logic. Because of this strict separation between data storage and data processing and the well-defined standard of LDAP as data access protocol it is easy to exchange LDAP servers without interfering with all the existing applications and clients that make use of the LDAP server.
LDAP is a very "convenient" protocol. There are several LDAP libraries for almost all programming languages which give easy and simple access to the LDAP server. Since it runs over TCP/IP and the full source of the libraries is available it should run on any computer that can compile C and provides TCP/IP networking. This allows for easy integration of LDAP into existing and new applications and, since LDAP is a non-proprietary standard in itself, it is a safe investment into the future of information technology and data access.
Links:
There is a need for a central database of users at HUJI. Currently there are many different user databases in use and only part of them are synchronized in terms of account names (and passwords), user information, user rights etc. Also there is no central registry of accounts, meaning that it is impossible to know for sure at which computers a given user can log on or whether he has more than one username on different machines. There is also no central place where one can obtain information about users (like name, location, phone, department ...) and today we have to query several databases and are still not sure that we got all the information (see below for details).
A central Directory of users at the University has many benefits:
It is feasible now to create such a Directory. Current technology gives us the tools necessary to implement HujiDir with existing standard technology since it now matches our demands on such a Directory:
Today standard solutions fulfill our demands:
Currently there is a wide range of unsynchronized systems in use:
Old systems will be supported and make use of the HujiDir. Many more recent computer systems are able to access an LDAP directory natively. But many old systems are not. They will be supported by middle ware that gives them an appropriate interface whilst using the LDAP directory in the background. Like this it is possible to integrate all systems in the University with the HujiDir. For example, the Register will be such a "middle tier" between all systems that currently use the Register and won't or can't make use of the LDAP Directory directly.
OTPs will be supported via an OTP server. A LDAP Directory server cannot, by it's nature, serve dynamic data. Therefore it can only store passwords and cannot serve One Time Passwords as we use now. Therefore all computer systems that will require OTP passwords will authenticate against an OTP server (e.g. Register) which in turn uses the LDAP directory as backend to retrieve user information. All other applications which need processed data will make use of such a "middle tier" to process the data from the LDAP Directory and deliver it to a client.
All new applications can access user information via a single, standard interface. This means that they will be less dependant on existing proprietary protocols or servers, usable in all departments of the University with only minor changes in their configuration. Also many existing applications can make use of the LDAP interface, which will bring them into the unified user management of the University.
Applications in the pipeline that could immediately benefit:
Several Management Interfaces are available for LDAP Directories. From simple command-line utilities (ldapsearch, ldapmodify, ldapadd) through batch tools (LDIF) to sophisticated GUI systems (Novell Console One, Netscape Delegated Administrator, etc.) all management programs make use of the LDAP interface to manipulate the Directory. Furthermore exist standard LDAP API libraries for most operating system and programming languages allowing us to always write the "missing link" ourselves. The LDAP server enforces user rights to objects and concurrent access from different tools is possible.
The content and structure of the Directory are the main issues after resolving the principal and technical questions. They will determine the usability, functionality and eventually the success of a University-wide Directory in the face of reality. The main factors are:
The Directory must contain the following items:
Access to the Directory is secured via SSL and a username/password authentication. This establishes a client as a defined user in the LDAP Directory. The exact type of the password depends on the LDAP server (plain-text, challenge-response, etc.). All operations of the client in the Directory are checked against the user's ACLs on the object in question. An anonymous user exists for public access, this allows for anonymous access to the Directory. Of course also the anonymous user has ACLs and can thus be prevented from accessing specific information (or all).
All security within the Directory is governed by the ACLs. This means that the sole responsibility lies with the administrators who manage the Directory and with defining correct data access rights when adding data. The exact granularity of the ACLs depends on the LDAP server, but some servers allow to define ACLs on the level of single attributes of single objects. Also inherited rights filters exist to allow assigning rights to a parent object (e.g. container) so that the assignment gives rights to all descendant objects or their attributes.
It is a strategic decision by the management whether to create the HujiDir. Everybody agrees that some kind of central information repository is necessary. Besides LDAP there are no competing standards that are so widely supported and available in open source as well as easy to use. Only with LDAP can we achieve the high level of integration that is needed now by the University. But the decision has to be done from above.
After deciding in favor of a central Directory, guidelines have to be established. Legal issues will dictate what information can be put into the Directory and made available to whom. The security infrastructure guarantees that only those who are allowed to can access information, but these definitions have to be given. Also administrative rights have to be carefully defined to enable everybody to edit the information that they are responsible for while preventing access to information that is restricted. This enables us to define local administrators with very limited and specialized administrative rights thus allowing true distributed and de-centralized administration.
First we have to decide on the LDAP technology to use. There are several possible LDAP servers on the market:
Only Novell's eNDS offers full integration with Windows on the OS level (Authenticate users, assign login rights, assign Applications to be used, etc.), if we disregard the Win2000 Active Directory . Since we have to support Hebrew for the end-users we have to support MS Windows as the base OS for the broad public. Therefore a tight integration of the user management with MS Windows is very important. Novell's eNDS integrates with Windows not via LDAP but via Novell's Client32 NetWare Client which accesses the eNDS server over Novell's NDAP protocoll (Novell Directory Access Protocol) if the eNDS server runs on NetWare. The advantage of this combination (eNDS on NetWare) is the easy integration with Windows which we cannot achieve via any other combination of LDAP Directory server and host OS. Novell NetWare with NDS has proven itself over the last 5 years as a reliable backbone for most PCs at the Hebrew University and the Computation Authority has staff experienced in NDS on NetWare on all campuses. With the addition of LDAP to the NDS server as directory access interface the formerly proprietory NDS server opens up to become a standard LDAP server which can be used by any LDAP client while in addition preserving the tight integration with Windows as a client OS.
Through the LDAP interface non-Windows clients can now easily access the NDS Directory and be integrated almost as tight as Windows into the Directory. Most modern Unix flavours support PAM and therefore a flexible authentication scheme (also against an LDAP server). Also for Macintosh clients there is native client support available (using NDAP to access the NDS). Applications can access the NDS via the new LDAP interface. This gives us a vertical integration from the OS level to the application level (assuming that future applications will use LDAP to access the Directory). All this together provides the highest level of integration possible while using only standard software.
Our current Novell NDS Directory serves as a pilot project. With the upcoming installation of eNDS 8.5 in Givat Ram all our Novell servers will also be LDAP servers. The Givat Ram NDS Directory will serve as a test suite to plan and develop the implementation of the HujiDir. On the NDS Directory we can test different forms of implementation at the Unix side and experiment with different schema layouts to best organize the information we want to store in the Directory. Doing all this with real-world data will allow us to plan the new Directory much faster than with special demo systems since we can make small test implementations that replace existing systems.
The most important part of planning is the design of the Directory. Some basic guidelines are:
Next we have to plan how to bring content into the Directory. The hookup of the Directory to existing master information repositories (like the Information System's database) has to be automatized to allow automatic updates of the Directory or vice versa. Likewise many other information systems have to be synchronized with the Directory, all this is done via custom-made batch tools which update either system on a regular base. This will very fast create the desired central user information database while keeping existing systems running as before. On the base of this synchronization we can slowly proceed to replace old legacy systems with direct access to the Directory (via LDAP). All units interviewed by me are ready to participate in the Directory at least by feeding their information into the Directory. The Directory Group will have to coordinate these efforts and solve any conflicts in the information provided by different sources.
After the planning we will proceed to implement the HujiDir in reality. We will create a new Directory according to the guidelines developed during planning, populate the Directory through synchonization with existing information systems and migrate existing applications to the new Directory. New systems and applications will be required to use the Directory as user repository from the beginning. At the same time legacy support will be implemented by helper servers (e.g. for OTPs) that work with the Directory as backend.
Finally all University systems that require any kind of information about people will use the HujiDir as a central information database and thus give true integration of all systems with the same username, password and other personal attributes.