Directory Service Design

To support its new extranet applications, the HugeCo corporate directory design had to be revisited and altered . HugeCo's IS staff began the redesign process by analyzing the needs of the new extranet applications.

Needs

Several needs drove the direction of the directory design for the HugeCo HRP extranet:

• The applications demand a flexible access control model that supports delegation of user account maintenance. Conceptually, two roles would be defined for the applications: manager and employee. One or more user administrators would be defined per authorized retailer, and those persons would be responsible for creating, maintaining, and deleting entries in the directory for all the employees allowed to use the HugeCo extranet applications. The directory must support this capability.

• The extranet applications were anticipated to have roughly the same performance requirements as the equivalent intranet applications. For example, the extranet Web servers that support the order tracking system would place the same load on the directory as the existing intranet servers did.

• The directory must be highly available and deliver a high level of service. This means that the directory needed to be replicated for fault tolerance.

• The directory must support configuration of customized schemas to support the specialized schema requirements of these extranet applications.

Data

Because 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. HugeCo's existing data policy stated the following:

• Data that is shared by more than one application should be stored in the directory service.

• The authoritative source for each data element stored in the directory must be defined.

• Data that is extremely sensitive or private should not be stored in the directory service unless there is an operational reason to do so. This kind of data includes payroll and employee benefit information.

• All legal requirements, including country and regional privacy laws in effect where HugeCo operates, must be followed.

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, to determine if the data was already available in the directory or other HugeCo databases, and to identify the authoritative data sources for each item.

Building on the concept of roles, the development team defined two new roles. The hugeCoHrpRetailEmployee role represents an employee at a retailer authorized to sell HugeCo's home renovation products, and hugeCoHrpRetailManager represents a manager at an authorized retailer.

Newly identified data elements necessary to support the extranet applications are discussed in the following section.

Schema

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: hugeCoHrpRetailer , which represents an authorized retail outlet; and hugeCoHrpRetailEmployee , which describes an employee of a HugeCo home products retail outlet. The hugeCoHrpRetailer object class is defined in Listing 26.1.

Listing 26.1 The hugeCoHrpRetailer Object Class

 objectclass hugeCoHrpRetailer     superior top     oid 1.2.3.4.5.6.8     required         hugeCoHrpRetailerID     allowed         hugeCoHrpProductAuthorized 

The hugeCoHrpRetailer object class is designed to be mixed in with the standard organization object class, and it augments the attributes from that object class with two additional attributes. The hugeCoHrpRetailerID attribute, used to name the entry, contains the unique authorized retailer ID assigned to that retailer. The hugeCoHrpProductAuthorized attribute contains a value for each HugeCo home renovation product line that the retailer is authorized to sell.

A sample hugeCoHrpRetailer entry might look like the one shown in Listing 26.2. This entry describes an authorized retailer of HugeCo products. Located in Tucson, Arizona, the retailer is authorized to sell four different HugeCo product lines.

Listing 26.2 A Sample hugeCoHrpRetailer Entry

 dn: hugeCoHrpRetailerID=882-501, ou=hugeCoHrpRetailers, ou=Extranet,  dc=HugeCo, dc=com objectclass: top objectclass: organization objectclass: hugeCoHrpRetailer hugeCoHrpRetailerID: 882-501 o: Jensen Home Improvement Products, Inc. postalAddress: 123 Anystreet $ Tucson, AZ $ USA 94432 st: AZ postalCode: 94432 telephoneNumber: [phone] facsimileTelephoneNumber: [phone] hugeCoHrpProductAuthorized: A733 hugeCoHrpProductAuthorized: J812 hugeCoHrpProductAuthorized: J813 hugeCoHrpProductAuthorized: J814 

The hugeCoHrpRetailEmployee object class is defined in Listing 26.3. This object class is designed to be mixed in with the standard inetOrgPerson object class, and it augments the attributes from that object class with four additional attributes:

1. hugeCoHrpRetailerID . Contains the retailer ID of the authorized HugeCo dealer that employs this person. This attribute is required; it makes no sense if a user has the hugeCoHrpRetailEmployee object class but is not associated with a retailer.

2. hugeCoHrpLastLogin . 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 hugeCoHrpLastLogin attribute allows the Web server that generates the start page to show only those notices posted since the last time the employee logged in.

3. hugeCoHrpEmployeeExpireDate . Contains the expiration date for this entry (which is removed on or after that date).

4. hugeCoEmployeeRole . Contains the value hugeCoHrpRetailEmployee if the entry describes an employee at a retailer, or the value hugeCoHrpRetailManager if the entry describes a manager at a retailer.

Listing 26.3 The hugeCoHrpRetailEmployee Object Class

 objectclass hugeCoHrpRetailEmployee     superior inetOrgPerson     oid 1.2.3.4.5.6.9     required         hugeCoHrpRetailerID     allowed         hugeCoHrpLastLogin         hugeCoHrpEmployeeExpireDate         hugeCoEmployeeRole 

A sample hugeCoHrpRetailEmployee entry might look like the one shown in Listing 26.4. This 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 hugeCoHrpRetailEmployee object class. The hugeCoHrpRetailerID attribute shows that this person works for retailer number 882-501, the hugeCoHrpLastLogin attribute shows the time that the employee last accessed the system, and the hugeCoHrpEmployeeExpireDate 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 section titled Directory Service Maintenance.

Listing 26.4 A Sample hugeCoHrpRetailEmployee Entry

 dn: uid=hreming, hugeCoHrpRetailerID=882-501, ou=hugeCoHrpRetailers,  ou=Extranet, dc=HugeCo, dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: hugeCoHrpRetailEmployee cn: Harold Remington sn: Remington uid: hreming ... (other inetOrgPerson attributes) ... hugeCoHrpRetailerID: 882-501 hugeCoHrpLastLogin: 200108300061302Z hugeCoHrpEmployeeExpireDate: 20030127 hugeCoEmployeeRole: hugeCoHrpRetailManager 

Namespace

To satisfy the delegation requirements of the extranet application framework, HugeCo decided to place the information about authorized retailers and their employees in a separate subtree . The complete HugeCo directory namespace design is shown in Figure 26.3.

Figure 26.3. HugeCo's Directory Namespace Design, Including Extranet Data

Placing all the information about authorized retailers into the ou=hugeCoHrpRetailers, ou=Extranet,dc=hugeco,dc=com subtree allows separate access control policies to apply to this information. It also allows this information to be replicated selectively across the firewall without requiring that all other corporate data in the directory also be made available outside the firewall.

20/20 Hindsight: Namespace Design and Fan-out

The initial design for HugeCo's Home Renovation Products extranet directory namespace called for a single container named ou=Retailers,dc=hugeco,dc=com that would contain all the HRP division retailers. Soon after completing the initial design, the extranet application developers realized that, if successful, their extranet application would encourage the development of other extranet applications within other HugeCo divisions. The original namespace design was clearly inadequate; placing all retailers underneath a single subtree would present problems as soon as the thousands of retailers of other HugeCo products were placed there.

To address this issue, the HRP extranet developers opted to create a container named ou=Extranet that could be subdivided as more extranet applications were developed. Within the ou=Extranet container, additional containers could be created to accommodate each new extranet application.

Underneath the retailers subtree is one tree for each retailer. The entries at the top of each tree are of the hugeCoHrpRetailer object class and contain information about the actual retailer (see the Schema section earlier in this chapter for more information about the hugeCoHrpRetailer object class). Within each retailer subtree 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 in its own subtree is to make it easy to delegate 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 placement of the appropriate access control directives in the hugeCoHrpRetailer entries.

You may be wondering why HugeCo decided to add the hugeCoHrpRetailerID 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). However, 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=hugeCoHrpEmployee ).

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 hugeCoHrpRetailer entry was 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 Directory Service Deployment section of this chapter.)

Topology

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.7 in Chapter 25).

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.

20/20 Hindsight: Search Performance across All Corporate Directory Data

One negative consequence of linking the extranet directory data into the HugeCo main directory tree is that searches across the whole organization (for example, searches rooted at dc=hugeco,dc=com ) require the LDAP client to chase a referral and then combine results from the two servers before presenting them to the client or directory-enabled application. Performance is slower than it would be if all entries were held within a single server.

In addition, some server capabilities become less useful in a distributed environment. For example, server-side sorting and paging through result sets works only within a single server. If a client application needs to contact two servers to satisfy a user's search request, and the user has specified that the results should be sorted, the client application needs to merge the entries returned from each server into a single list before presenting it to the user.

After some more thought, HugeCo staff realized that the HRP extranet applications didn't really need to be aware of the intranet directory data, and the intranet applications had no real need to be aware of the extranet data. Therefore, the designers decided to remove the referrals from the regional servers, essentially making the extranet data a separate, unconnected directory ”which is acceptable for the time being. In the future, if the extranet and intranet directory data need to be combined, the replication architecture can be altered so that extranet data is replicated to each of the regional servers.

Replication

The primary goal of replication in HugeCo's existing 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 initially to deploy a master server and two read-only replicas, thereby increasing the reliability and scalability of the extranet directory data. The client connection load is balanced across the two read-only servers with a Nortel Networks Alteon Load Optimizer load balancer. The virtual IP address of the load-balanced directory servers is known by the domain name hrpdirectory.extranet.hugeco.com . If additional replicas need to be added, they can be deployed and load-balanced in the same fashion.

Privacy and Security

The security 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.

Access Control

Before 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 used merely 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.

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 approach not only reduces costs for HugeCo, but is 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:

• Each retailer must designate one or more points of administrative contact. These administrators are responsible for adding and deleting local users and updating certain information about the retailer.

• The administrative contacts may create and delete users as they see fit.

• Users created by an administrative contact may not update their own entries.

• Only HugeCo personnel may add or delete the entry representing the retailer.

• Only HugeCo personnel may add or delete the entry representing the administrative contact.

See Figure 26.6 for an illustration of this delegated access control policy.

Figure 26.6. The Delegated Access Control Policy

Protection against Attack

Connections 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, HugeCo's security design team decided to use Secure Sockets Layer (SSL) session-layer encryption to protect sensitive data during transit. With SSL in place, 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.

Dangers of Delegation

When you're 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 problem, 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. Thus 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 foolproof 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. Of course, it is still up to the user interface to provide a helpful error message in the event of a naming collision. But 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.

In addition, firewall technology is used to reduce exposure to hostile parties on the Internet. The Web servers in the application architecture are protected by a firewall that permits only inbound connections to the HTTPS (HTTP-over-SSL) port (443). Inbound connections to any other port are prohibited, and all outbound connections are prohibited . Figure 26.7 illustrates this part of the architecture.

Figure 26.7. The Web Tier of HugeCo's Extranet Architecture

Preventing outbound connections keeps your servers from being used as springboards for further attacks if they are compromised. You can also use an intrusion detection system to detect when outbound connections originate from your Web servers to external addresses. Such outbound connections almost certainly indicate that your servers have been compromised.

The application servers that support the business logic of the application, the directory servers, and the database server are further protected by an additional firewall that permits traffic to pass only from the Web servers to the application servers, and only on TCP port 8003, which is the port that the Web servers and application servers have been configured to use. Figure 26.8 depicts this layer of the application architecture.

Figure 26.8. The Application Tier of HugeCo's Extranet Architecture

Inserting an additional layer of firewall protection adds further protection for the sensitive data stored on the directory and database servers. Even if the Web server is compromised by an outside attacker, the only further attack that can be mounted is one that originates from one of the Web servers and is directed against the application servers using TCP port 8003. Although the additional firewall doesn't make it impossible for your data to be compromised, it makes it much more difficult and offers a much higher level of security than would be possible if the firewall were not present.