Introduction

 < Day Day Up > 



Setting up directory services from scratch would be a clean design problem, but it is not a likely scenario. Usually, the directory services are already in place, and your job is to optimize access to the existing infrastructure. The following is a typical scenario:

You have several applications using a database for user authentication. Let us assume that you have a standard RDBMS in place, but that some applications use a proprietary database for historical reasons. Furthermore, you need authentication for your intranet; you want to enable users to access static Web pages containing sensitive data; and you need authentication for intranet applications such as CGI (common gateway interface) scripts, PHP scripts, or application servers. Most of these applications need authentication as well as additional information about the user that has been authenticated, for example, the user name, the department the user is in, and perhaps some profiling information. Obviously, you need the same information regardless of which point you connect from within the enterprise. Consequently, the first step will be to provide an authentication mechanism implemented as a directory.

Once you have the directory services in place and your authentication mechanism fine-tuned, you will begin to extend it. Any authentication process holds information about persons, for example, UserID, name, and password. LDAP can hold much more information, so why not use the LDAP server to provide additional information about these persons? Examples of information needed include:

  • Phone and fax numbers of your employees

  • Physical location of employees, such as town, building, floor, and room number

  • Computer equipment that the employees are using

  • Computer systems that the employees have access to

  • Printers that the employees can use

As you begin thinking about useful information for different departments, this list will grow longer.

At this point, it is likely that you will recognize the need for a redesign. You will begin to think about questions like data replication, data distribution, and data security. And you will begin to think about what you should do with the "release zero" of your global directory services. Throw it away and design a new version from scratch? Extend your existing implementation? This chapter was written to help you decide how to resolve these and other questions about your particular situation.

Note that the design phase of directory services is the most important of phase of all because a well-designed system will prevent problems from occurring later on. It is very difficult to recover from prominent design errors, and even very grave design errors may not become apparent until late in the implementation phase.

In contrast, with a good design in hand, implementation is straightforward. It is somewhat like writing a book: Once you have written a good outline, you have completed as much as half the work. So the more time you spend on the design phase, the less effort you will need to expend during the implementation phase. Of course, your time is not unlimited, and you cannot design forever. At some point, you will have to compromise between the time spent on design and the final benefit you gain with eventual further refinement of your design. Your goal should be to make the design "good enough." This is a question of experience, but the point is: Do not stint on the time spent during the design phase.



 < Day Day Up > 



The ABCs of LDAP. How to Install, Run, and Administer LDAP Services
The ABCs of LDAP: How to Install, Run, and Administer LDAP Services
ISBN: 0849313465
EAN: 2147483647
Year: 2003
Pages: 149

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net