Understanding and Deploying LDAP Directory Services > 26. Case Study: An Enterprise with an Extranet > Directory Service Design |
Directory Service DesignTo support its new extranet applications, the HugeCo corporate directory design had to be revisited and altered . To start the redesign process, HugeCo's IS staff began by analyzing the needs of the new extranet applications. NeedsA number of needs drove the direction of the directory design for the HugeCo HRP extranet:
All these needs taken together are not too different from the needs of HugeCo's intranet. The main difference is the need for delegation capabilities. DataBecause the extranet would be a set of new applications that leveraged an existing directory installation, HugeCo needed to review its existing data policy statement to see if it was valid for the new extranet applications. Recall the policy statement presented in Chapter 25:
After review, it was apparent that this data policy statement was suitable for the new extranet, and HugeCo staff began to define the new data elements needed to support these applications, determine if the data was already available in the directory or other HugeCo databases, and identify the authoritative data sources for each item. Building on the concept of roles, two new roles were defined: hcHrpRetailEmployee and hcHrpRetailManager . The hcHrpRetailEmployee role represents an employee at a retailer authorized to sell HugeCo's home renovation products, and the hcHrpRetailManager represents a manager at an authorized retailer. Newly identified data elements necessary to support the extranet applications are discussed in the following section. SchemaAs with the existing schema described in Chapter 25, HugeCo chose to subclass standard object classes to represent the new objects that would be stored in the directory. Two new object classes were defined ” hcHrpRetailer , which represents an authorized retail outlet; and hpHrpRetailEmployee , which describes an employee of a HugeCo home products retail outlet. The definition of the hcHrpRetailer object class is shown in Listing 26.1. Listing 26.1 The hcHrpRetailer object classobjectclass hcHrpRetailer superior top oid 1.2.3.4.5.6.8 required hcHrpRetailerID allowed hcHrpProductAuthorized The hcHrpRetailerID attribute, used to name the entry, contains the unique authorized retailer ID assigned to that retailer. The hcHrpProductAuthorized attribute contains a value for each HugeCo home renovation product line the retailer is authorized to sell. A sample hcHrpRetailer entry might look like the one shown in Listing 26.2. Listing 26.2 A sample hcHrpRetailer entrydn: hcHrpRetailerID=882-501, ou=hcHrpRetailers, ou=Extranet, dc=HugeCo, dc=com objectclass: top objectclass: organization objectclass: hcHrpRetailer hcHrpRetailerID: 882-501 o: Jensen Home Improvement Products, Inc. postalAddress: 123 Anystreet $ Tucson, AZ $ USA 94432 st: AZ postalCode: 94432 telephoneNumber: +1 520 555 0499 facsimileTelephoneNumber: +1 520 555 3882 hcHrpProductAuthorized: A733 hcHrpProductAuthorized: J812 hcHrpProductAuthorized: J813 hcHrpProductAuthorized: J814 The entry shown in Listing 26.2 describes an authorized retailer of HugeCo products. The retailer, located in Tucson, Arizona, is authorized to sell four different HugeCo product lines. The definition of the hcHrpRetailEmployee objectclass is shown in Listing 26.3. Listing 26.3 The hcHrpRetailEmployee object classobjectclass hcHrpRetailEmployee superior inetOrgPerson oid 1.2.3.4.5.6.9 allowed hcHrpRetailerID hcHrpLastLogin hcHrpEmployeeExpireDate hcEmployeeRole The hcHrpRetailerID attribute contains the retailer ID of the authorized HugeCo dealer that employs this person. The hcHrpLastLogin attribute contains the date and time that the employee last logged in to the system. The initial page shown to each employee contains a list of new product notices, promotions, and alerts, and the hcHrpLastLogin attribute allows the Web server that generates the start page to show only those notices posted since the last time the employee logged in. The hcHrpEmployeeExpireDate attribute contains the expiration date for this entry (which is removed on or after that date). The hcEmployeeRole attribute contains the value hcHrpRetailEmployee if the entry describes an employee at a retailer, or the value hcHrpRetailManager if the entry describes a manager at a retailer. A sample hcHrpRetailEmployee entry might look like the one shown in Listing 26.4. Listing 26.4 A sample hcHrpRetailEmployee entrydn: uid=hreming, hcHrpRetailerID=882-501, ou=hcHrpRetailers, ou=Extranet, dc=HugeCo, dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: hcOracleUser objectclass: hcHrpRetailEmployee cn: Harold Remington sn: Remington uid: hreming (other inetOrgPerson attributes) hcHrpRetailerID: 882-501 hcHrpLastLogin: 199808300061302Z hcHrpEmployeeExpireDate: 19990127 hcEmployeeRole: hcHrpRetailManager hcOracleLogin: hreming hcOraclePassword: FooD%golf!! As you can see, the entry contains the attributes you would expect to see in a typical inetOrgPerson object, such as cn (common name), sn ( surname ), and uid (user identifier). However, this entry can also contain two additional attributes because it is of the hcHrpRetailEmployee object class. The hcHrpRetailerID attribute shows that this person works for retailer number 882-501, the hcHrpLastLogin attribute shows the time that the employee last accessed the system, and the hcHrpEmployeeExpireDate attribute gives the date on which the employee record will expire if it is not renewed by the manager. More information on the employee expiration policy is given later in this chapter in the "Maintenance" section. Several other attributes allow a person to access the HugeCo Oracle database servers. The auxiliary objectclass hcOracleUser has two optional attributes, hcOracleLogin and hcOraclePassword , which respectively specify the Oracle login ID and password that should be used by Web server CGIs that need to connect to the Oracle database on behalf of the user. NamespaceTo satisfy the delegation requirements of the extranet application framework, HugeCo decided to place the information about authorized retailers and their employees into a separate subtree . The complete HugeCo directory namespace design is shown in Figure 26.3. Figure 26.3 HugeCo directory namespace design, including extranet data.Placing all the information about authorized retailers into the ou=hcHrpRetailers, ou=Extranet, dc=HugeCo, dc=com subtree allows this information to be selectively replicated across the firewall without requiring that all other corporate data in the directory also be made available outside the firewall.
Underneath the retailers subtree, there is one tree for each retailer. The entries at the top of each tree are of the hcHrpRetailer object class and contain information about the actual retailer (see the "Schema" section earlier in this chapter for more information about the hcHrpRetailer objectclass). Within each retailer subtree, there is an entry for the primary contact person (usually the department manager) and a container named ou=employees . This container holds information about additional employees, if any, who are authorized to place and track orders. The intent of placing data about each retailer into its own subtree is to allow easy delegation of the administration of that information. For example, the manager at any particular retailer could be delegated the ability to update information about the retailer and create new employee entries, but only within his or her particular retailer subtree. Early in the design process it was unclear whether it was a good idea to allow such delegation, but the designers decided to construct a directory namespace that could support delegation if needed. Delegation can be enabled by placing the appropriate access control directives in the hcHrpRetailer entries. You may be wondering why HugeCo decided to add the hcHrpRetailerID attribute to entries representing employees. On the surface, it seems unnecessary because all the employees of a given retailer are held underneath the entry describing the retailer (see Figure 26.4). If you want to find all the employees of a given retailer, this construction allows you to perform a subtree search rooted at the retailer entry with a filter of (objectclass=hcHrpEmployee) . Figure 26.4 A portion of HugeCo's directory representing a single retailer and its employees.So why is it desirable to include the retailer ID in each person entry? Sometimes it is necessary to map from an employee's entry back to his or her retailer. Although it would be possible to walk up the directory tree until an hcHrpRetailer entry is located, storing the retailer number in the entry allows the corresponding retailer record to be located with a single search operation. (For an example of an application that performs exactly this operation, see the discussion of how personal start pages are generated in the "Deployment" section of this chapter.) TopologyAs discussed in Chapter 25, HugeCo's directory is partitioned along regional lines, with each major locality mastered in a different server and replicated to all the other servers via a central replication hub (refer to Figure 25.8). When adding the extranet subtree to the directory tree, HugeCo's directory designers opted to create an additional directory partition holding all the data at or below the ou=Extranet entry. This approach, which is consistent with the existing partitioning scheme, is depicted in Figure 26.5. Figure 26.5 HugeCo directory partitions, including extranet data.The designers initially used referrals in each of the regional servers to link the extranet data into the directory information tree (DIT). Whenever any of the regional servers receive an LDAP operation that needs data from the ou=Extranet subtree, a referral to the extranet server is generated.
ReplicationAs stated in Chapter 25, the primary goal of replication in HugeCo's directory deployment is to increase the read and search capacity of the directory in an incremental fashion. HugeCo decided to stick with this approach as it extended its applications to the extranet. Extranet data can be replicated as needed to increase capacity for the extranet applications. HugeCo planned to initially deploy two read-only replicas, which increased the reliability and scalability of the extranet directory data. Both read-only replicas are known by a single domain name, hrpdirectory.extranet.hugeco.com . This domain name is associated with the IP addresses of both replicas, and the addresses are returned in round- robin fashion. If additional replicas need to be added, they can be deployed and their IP addresses added to the domain name system. Privacy and SecuritySecurity design for HugeCo's internal directory server deployment focused on two major issues: access control on directory data to support delegated administration, and protection against attack. Security Design: Access ControlBefore we discuss the access control policies in effect for the directory, we should clarify that the order entry and tracking application has its own set of access control policies that are separate from the directory access control policy. The directory is used to authenticate users, produce the personalized start page for retail employees, and determine whether a given user may access a given URL within the order entry application. The directory is merely used as a repository for the information that the Web application uses to make its access control decisions. The access control policy in effect for the directory itself controls who may access the actual directory content. HugeCo has a restrictive access control policy in effect for its directory data. Employees may update only a few fields in their own entries, as described in Chapter 25. Within the subtree used to hold information about employees of authorized retailers, a different set of access control policies is in force. The goal of these policies is to delegate administration of the individual retailer information to a responsible person at each retailer. This not only reduces costs for HugeCo, but it's absolutely necessary: Employees of the retailers are not HugeCo employees, so HugeCo has no knowledge of when these employees are hired or terminated . To meet this requirement, the following access control policies were developed:
See Figure 26.6 for an illustration of this delegated access control policy. Figure 26.6 The delegate access control policyDangers of Delegation When delegating privileges, it's also important to consider the capabilities that those privileges grant, especially with respect to directory-enabled applications. For example, what would happen if administrative contacts at retailers were able to create entries with the same user identifier (UID) as an existing entry somewhere else in the directory? If the new entry were within a separate directory tree, its name wouldn't collide with the other entry; however, applications that expect UIDs to be unique across the directory (authentication applications behave this way) may malfunction when they discover multiple matching entries. To prevent this, applications should check before adding new entries to make sure that no undesirable attribute collisions occur. If, for example, someone attempts to add a new entry with the UID jsmith to a directory, but there is an existing jsmith somewhere else in the directory, the application could reject the addition with a helpful error message. Similarly, the application could check whether modifying or renaming an entry is legal and does not cause a collision. However, this approach requires that you force all updates to the directory through a single application such as a Web front end. This way you lose the ability to deploy general-purpose clients. And there may be no practical way to prevent someone from using one of these general-purpose clients . A much more bulletproof solution is to enforce the attribute uniqueness constraints on the server itself. Netscape Directory Server (version 4.0 and later) includes a general attribute- uniqueness plug-in that allows the server to reject any update to the directory that causes an undesired attribute value collision. For example, the plug-in can be configured to reject any modifications to directory data that would cause two entries to have the same UID. Using this plug-in means that no matter how clever or determined a person is, he or she cannot bypass the uniqueness constraints you have configured. Security Design: Protection Against AttackConnections from HugeCo's authorized retailers to the Web-based application and to the directory traverse the public Internet. To protect against eavesdropping and man-in-the-middle attacks, it was decided to use secure sockets layer (SSL) session-layer encryption to protect sensitive data during transit. All protocols used to communicate with authorized retailer sites (HTTP, LDAP, IMAP) are performed over SSL-secured connections. SSL-capable web browsers and electronic mail user agents were deployed at each retailer site. Using this approach, even if data were intercepted in transit, the eavesdropper would not be able to make use of the encrypted data without a great deal of effort.
|
Index terms contained in this sectionaccess controlsHugeCo case study case studies HugeCo data 2nd 3rd namespaces 2nd 3rd 4th 5th 6th 7th needs 2nd 3rd 4th 5th replication 2nd schema 2nd 3rd 4th 5th 6th security and privacy 2nd 3rd 4th 5th 6th 7th 8th topology 2nd 3rd 4th data HugeCo case study 2nd 3rd directories case studies HugeCo 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 encryption HugeCo case study 2nd extranets HugeCo case study data 2nd 3rd namespaces 2nd 3rd 4th 5th 6th 7th needs 2nd 3rd 4th 5th replication 2nd schema 2nd 3rd 4th 5th 6th security and privacy 2nd 3rd 4th 5th 6th 7th 8th topology 2nd 3rd 4th hcHrpRetailEmployee object class HugeCo case study schema sample entry hcHrpRetailer object class HugeCo case study schema sample entry HugeCo case study data 2nd 3rd namespaces 2nd 3rd 4th 5th 6th subtrees needs 2nd access controls custom schema performance requirements replication 2nd schema 2nd 3rd 4th 5th 6th 7th hcHrpRetailEmployee object class 2nd hcHrpRetailer object class 2nd security and privacy access control 2nd 3rd 4th 5th 6th encryption 2nd topology 2nd partitions search performance namespaces HugeCo case study 2nd 3rd 4th 5th 6th subtrees needs HugeCo case study 2nd access controls custom schema performance requirements partitions topology HugeCo case study privacy HugeCo case study access control 2nd 3rd 4th 5th 6th encryption 2nd replication HugeCo case study 2nd schema HugeCo case study 2nd 3rd 4th 5th 6th hcHrpRetailEmployee object class 2nd hcHrpRetailer object class 2nd search performance HugeCo case study security HugeCo case study access control 2nd 3rd 4th 5th 6th encryption 2nd subtrees namespaces HugeCo case study topology HugeCo case study 2nd partitions search performance |
2002, O'Reilly & Associates, Inc. |