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. NeedsSeveral needs drove the direction of the directory design for the HugeCo HRP extranet:
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. HugeCo's existing data policy stated the following:
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. SchemaHugeCo 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 Classobjectclass 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 Entrydn: 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: +1 520 555 0499 facsimileTelephoneNumber: +1 520 555 3882 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:
Listing 26.3 The hugeCoHrpRetailEmployee Object Classobjectclass 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 Entrydn: 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 NamespaceTo 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.
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.) TopologyHugeCo'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.
ReplicationThe 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 SecurityThe 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 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 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:
See Figure 26.6 for an illustration of this delegated access control policy. Figure 26.6. The Delegated Access Control Policy
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, 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.
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. |