Understanding and Deploying LDAP Directory Services > 23. Case Study: Netscape Communications Corporation > Directory Service Design |
Directory Service DesignIn this section we describe Netscape's directory design and how it was developed. NeedsAs in many businesses, Netscape's directory needs were driven by two factors: the need to support a wide range of applications and the need to deploy them in a manageable and cost-effective manner. As mentioned previously, Netscape's IS department is charged with providing computing support to employees at the main campus and satellite offices. With few exceptions, IS provides all the hardware, software, and network connectivity for every employee. (This is in contrast to the decentralized support methods that will be described in Chapter 25.) Despite this centralization, minor political problems arose when the directory service was being deployed. Obtaining a synchronization file with all full-time employees, contractors, temporary employees, and contingent employees proved difficult, and the issue had to be escalated to senior management. When the synchronization file was obtained, IS staff needed to spend a significant amount of time connecting existing IS work processes to the directory. This required some modifications to existing HR database tables and associated user interfaces. Another constraint was that the staff involved in the directory design and deployment, although extremely skilled, needed some time to become familiar with directory technology. Fortunately, the developers responsible for developing the directory server software (the Netscape Directory Server) were literally next door. This provided immense benefits for both IS and the Directory Server software engineering team; questions from IS were handled quickly and accurately, and Engineering obtained valuable information on how the product worked in an actual deployment. In essence, IS still provides an ongoing directory pilot that continually feeds back useful information to Engineering, ultimately resulting in a higher-quality , more functional product. One of the primary drivers for the directory deployment was the support of Netscape's SuiteSpot family of directory-enabled products, including Netscape Messaging Server (electronic mail), Netscape Collabra Server (internal discussion groups), Netscape Enterprise Server (internal Web publishing), Netscape Certificate Server (for public-key certificates), and Netscape Calendar Server (for workgroup scheduling). Each of these products is directory-enabled and can utilize the directory for user and group management and access control. Additionally, employees have become very dependent on the Netscape Phone Book ”an internally developed application that allows quick and easy lookup of contact information and location information for people and meeting rooms. The directory is also used for IS-specific work processes, serving as the focal point for creation or removal of resources when a person joins or leaves Netscape. For example, when an employee is hired , a directory entry is created, triggering processes that create UNIX and Windows NT accounts, assign telephone numbers , add the employee to the security/badging database, allocate a network port, and add the employee to certain companywide , divisionwide, and workgroup-specific mailing lists. Early in the design process, IS made the assumption that directory users needed to feel confident that the central repository of directory data was secure, stable, valuable, and accurate. These needs led to the conclusions described in the following list:
Additionally, the directory itself must be flexible enough to accommodate new applications, and it must scale well so that users always receive adequate performance. DataAs mentioned in the previous section, the primary drivers behind the directory service revolved around the directory-enabled applications slated for deployment. Those applications had well-defined schema requirements, which made identification of the necessary data elements very straightforward. What was less straightforward, however, was identifying the "owner," or authoritative source, of each data element. The IS organization began by developing a conceptual framework for understanding the directory, external data sources, and external users of the data. This framework is pictured in Figure 23.1. Figure 23.1 A conceptual framework for data sources.Data owners are the databases that contain authoritative enterprise data. For example, data stored in the PeopleSoft system is considered authoritative for certain elements such as a person's name and home postal address. The Private Branch Exchange (PBX) telephone system is considered authoritative for office telephone numbers. We'll describe the process that synchronizes data between the directory and other data sources in the "Maintaining Data" section of this chapter. Data is collected from the authoritative data sources and placed into the directory. In this role, the directory serves as a central repository ”a rendezvous point where applications can meet to obtain data about people, groups, and other business- related objects. The directory serves a valuable role by publishing and grouping the data synchronized from the various distinct data sources. In some cases, the directory itself is considered authoritative for certain data elements such as email addresses. For these data elements, the directory functions simultaneously as a data owner and the central repository. Data users are applications, business processes, and end users that make use of the directory data stored in the central repository. As soon as the fundamental data model had been developed, IS refined the data plan further by establishing the following basic guidelines for deciding whether a given data element should be stored in the directory:
Next, a detailed data element inventory was completed. This inventory described each data element, the directory's attribute name for it, the authoritative source, and the consumers that use it. A portion of that inventory is shown in Table 23.1. Table 23.1. A portion of the data element inventory
Finally, a set of synchronization procedures were developed that propagate changes from the external authoritative data sources into the directory. These synchronization procedures were designed to capture changed data in the external authoritative data source and apply updates to the directory. SchemaThe schema used in the central directory is comprised of three distinct sets of schema definitions:
The custom schema definitions were added only after carefully examining available schema elements and determining that no existing attribute types met Netscape's needs. All schema extensions were implemented as auxiliary, or "mix-in," object classes. To illustrate , consider the definition of the nscpPerson object class shown in Listing 23.1. Listing 23.1 The nscpPerson object classobjectclass nscpPerson allows nscpBadgeImage, nscpPersonExpDate, nscpCurContactInfo, nscpBuildingNum, nscpBuildingLev, nscpHarold, This object class contains only the Netscape-specific attributes. It is intended that entries in the directory that describe people are of object classes inetOrgPerson and nscpPerson . This allows the entry to contain any of the attributes allowed by either the inetOrgPerson or nscpPerson object classes. In this way, Netscape extended the schema with business-specific attributes without altering the standard object class definitions. The added attributes were as follows :
NamespaceNetscape's directory namespace is shown in Figure 23.2. Figure 23.2 Netscape directory namespace.The organizational units in Netscape's directory namespace contain the following data:
There are several important points to note about this namespace design. To some extent, the portion of the global directory namespace Netscape uses at this time is unimportant because the internal directory is not available outside Netscape's firewall. However, if Netscape should want to share this information with external business partners in the future, it would be necessary to choose a portion of the namespace that cannot conflict with namespaces in use by other businesses. To accomplish this, Netscape chose to use a naming method that leverages the existing Domain Name System (DNS) infrastructure to provide a unique namespace. The top of Netscape's namespace is an entry named dc=netscape , dc=com . This name is derived from Netscape's assigned domain name, netscape.com . The other option would have been to use the X.500 naming method, which is based on a country-locality-organization name hierarchy. Using this scheme, Netscape's tree would have been rooted at o=Netscape Communications Inc. , st=California , c=US , or possibly o=Netscape Communications Inc. , c=US . Netscape chose the DNS-derived names because they are shorter and do not require registration with any standards organization (other than registered domain name). After the directory suffix was chosen , Netscape's IS department needed to decide how the directory information would be structured. The following factors were taken into consideration in arriving at the final decision:
A flat namespace beneath ou=People was chosen to avoid the headaches caused when people move between departments. Within the ou=People container, the uid (user ID) attribute was chosen as the naming attribute for entries. This has two desirable properties. First, the uid needs to be unique anyway because the employee's electronic mail address is uid@netscape.com . Second, because the namespace is flat, any attempts to create a duplicate uid would be rejected by the directory server (because the new entry would have the same distinguished name as an existing entry). One trade-off in using a flat namespace under ou=People is that directory browsing is less interesting ”all employees would appear in a single, flat list of names. Browsing is more useful when the namespace reflects some organizational hierarchy. Netscape directory deployers realized that there were multiple hierarchies present in the directory data. For example, each employee at Netscape is associated with a particular department, and this represents one type of hierarchy present in the data. Each employee also has a manager, and the reporting hierarchy represents a different type of hierarchy. Instead of favoring one type of hierarchy, the deployers opted to make the namespace independent of any particular hierarchy. To construct multiple alternative hierarchies, such as the reporting hierarchy, DN-valued attributes are used. For example, each employee's entry contains a manager attribute that holds the DN of the employee's manager. A directory application can use this information to allow a user to jump to an employee's manager or to list all the employees who report to a given manager. TopologyThe topology chosen for the Netscape directory deployment is very simple: the entire directory is contained in a single partition. There were two considerations that led to this decision:
For these reasons, a single-partition design was chosen. ReplicationNetscape uses directory replication primarily as a means of providing sufficient directory capacity for its directory-enabled applications such as messaging and calendaring. This is the primary motivator behind the replication architecture. The overall replication architecture is shown in Figure 23.3. Figure 23.3 The Netscape IS replication architecture.There are several important points about the replication architecture:
This particular design leverages the strengths of the Netscape Directory Server ”namely, its ability to store a large number of entries while still providing excellent performance. If your directory server software limits you to a particular number of entries per partition, a more complicated replication architecture may be required. On the other hand, the presence of the replication hub is a concession to the single-master nature of Netscape's Directory Server. Because there is a single updatable server, it is highly desirable to keep its load as light as possible ”which is why a replication hub is used. If your directory server software supports multimaster replication, your architecture can do away with the concept of a replication hub. Privacy and SecuritySecurity design for Netscape's internal Directory Server deployment focused on two major issues: access control on directory data and protection against attack. The data contained in Netscape's internal directory is primarily composed of public information that can be viewed by any employee. However, several attributes of person entries are potentially sensitive in nature, such as the employee home address and telephone number. To fully understand the security issues associated with each directory attribute, Netscape's IS department developed a security matrix. For each type of object stored in the directory, the matrix describes the attributes present in that entry and the security restrictions in effect for those attributes. For example, the electronic mail address for a given employee is considered public information; it is essential for other employees to know a given employee's email address for Netscape business processes to proceed. On the other hand, the employee's home address is considered sensitive information to protect employee privacy. During the development of this security matrix, Netscape's legal department offered advice about which attributes might be considered sensitive information. For each attribute considered sensitive, a policy was developed that describes who may view and update it. A portion of the final security matrix is shown in Table 23.2. Table 23.2. An excerpt from the Netscape security matrix
Note that the update policy also allows an individual employee to decide whether certain information should be published in the directory at all. For example, the authoritative source for the employee's home address is the PeopleSoft database. Unlike most of the other directory attributes, the home address is not automatically synchronized from PeopleSoft to the directory. Instead, the employee may place a home address in the directory if he or she desires. This policy places complete control of certain sensitive information such as home addresses in the hands of the employee. Another part of Netscape's directory security design involves protecting the directory from several types of assault. Because Netscape's internal directory is used only by employees and contractors, certain assumptions make it unnecessary to protect against certain types of attacks. Employees are trusted to conform to organizational policy, so disciplinary action can be levied against an employee who perpetrates a directory attack. Such attacks (of which there have been none to date) include denial-of-service attacks and impersonation attacks. Despite this, however, certain other precautions need to be taken because Netscape uses leased lines provided by a third party. Netscape does not control the physical security of these lines; therefore, data transmitted across them cannot be guaranteed safe from eavesdropping. The following precautions are in place:
In summary, Netscape's security architecture for the directory and the data it contains are tuned to the particular needs of the business.
|
Index terms contained in this sectionaccuracyneeds Netscape case study attributes nscpPerson object class 2nd 3rd case studies Netscape Communications Corporation central data repository data element inventory data model data owners namespace 2nd 3rd 4th 5th 6th needs 2nd 3rd 4th 5th 6th 7th 8th 9th privacy and security 2nd 3rd 4th 5th 6th 7th 8th replication 2nd 3rd schema 2nd 3rd 4th topology users central data repository Netscape Communications Corp. custom schema Netscape case study data Netscape Communications Corp. case study central repository model owners directories case studies Netscape Communications Corporation 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th HTTPS (Hypertext Transfer Protocol over SSL) Hypertext Transfer Protocol over SSL inventories data element Netscape Communications Corp. case study namespaces Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th oranizational units 2nd 3rd needs Netscape Communications Corp. case study 2nd 3rd 4th 5th accuracy data value security stability Netscape Communications Corporation case study central data repository data element inventory data model data owners namespace 2nd 3rd 4th 5th 6th needs 2nd 3rd 4th 5th 6th 7th 8th 9th replication 2nd 3rd schema 2nd 3rd 4th security 2nd 3rd 4th 5th 6th 7th 8th topology users nscpPerson object class Netscape schema 2nd 3rd attributes 2nd 3rd object classes nscpPerson Netscape schema 2nd 3rd 4th 5th 6th organizational units Netscape directory namespace 2nd 3rd owners data Netscape Communications Corp. POSIX schema Netscape case study privacy Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th 7th security matrix replication Netscape Communications Corp. case study 2nd 3rd schema Netscape Communications Corp. case study 2nd 3rd 4th nscpPerson object class 2nd 3rd 4th 5th 6th security needs Netscape case study Netscape Communications Corp. case study 2nd 3rd 4th 5th 6th 7th matrix stability needs Netscape case study topologies Netscape Communications Corp. case study single-partition design users Netscape Communications Corp. case study value needs Netscape case study |
2002, O'Reilly & Associates, Inc. |