Determining and Prioritizing Users Needs and Expectations

Understanding and Deploying LDAP Directory Services > 26. Case Study: An Enterprise with an Extranet > Directory Service Design

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053062216123029244129097065173203124

Directory Service Design

To 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.

Needs

A number of 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 manager would be defined per authorized retailer, and that person 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.

  • It was anticipated that the extranet applications would have roughly the same performance requirements as the equivalent intranet applications. For example, the extranet Web servers that support the order tracking system should place the same load on the directory as the existing intranet servers. The other applications place a much lighter load on the directory.

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

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

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.

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. Recall the policy statement presented in Chapter 25:

  • 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, 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.

Schema

As 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 class

objectclass 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 entry

dn: 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 class

objectclass 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 entry

dn: 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.

Namespace

To 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.

20-20 Hindsight: Namespace Design and Fanout

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, 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.)

Topology

As 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.

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 (e.g., 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.

Also, 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. In light of this, 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

As 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 Security

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.

Security Design: 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 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:

  • Each retailer must designate a single point of administrative contact. This person is 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

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

Figure 26.6 The delegate access control policy

Dangers 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 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, 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.



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

access controls
          HugeCo 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

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