Lightweight directory access protocol, (LDAP) trusted processing of unique identifiers

[0002] 1. Technical Field

[0003] This invention relates generally to providing directory services in a distributed computing environment.

[0004] 2. Description of the Related Art

[0005] A directory service is the central point where network services, security services and applications can form an integrated distributed computing environment. Typical uses of a directory services may be classified into several categories. A “naming service” (e.g., DNS and DCE Cell Directory Service (CDS)) uses the directory as a source to locate an Internet host address or the location of a given server. A “user registry” (e.g., Novell NDS) stores information about users in a system composed of a number of interconnected machines. The central repository of user information enables a system administrator to administer the distributed system as a single system image. Still another directory service is a “white pages” lookup provided by some e-mail clients, e.g., Netscape Communicator, Lotus Notes, Endora and the like).

[0006] With more and more applications and system services demanding a central information repository, the next generation directory service will need to provide system administrators with a data repository that can significantly ease administrative burdens. In addition, the future directory service must also provide end users with a rich information data warehouse that allows them to access department or company employee data, as well as resource information, such as name and location of printers, copy machines, and other environment resources. In the Internet/intranet environment, it will be required to provide user access to such information in a secure manner.

[0007] To this end, the Lightweight Directory Access Protocol (LDAP) has emerged as an IETF open standard to provide directory services to applications ranging from e-mail systems to distributed system management tools. LDAP is an evolving protocol that is based on a client-server model in which a client makes a TCP/IP connection to an LDAP server, sends requests, and receives responses. The LDAP information model in particular is based on an “entry,” which contains information about some object. Entries are typically organized in a specified tree structure, and each entry is composed of attributes.

[0008] LDAP provides a number of known functions including query (search and compare), update, authentication and others. The search and compare operations are used to retrieve information from the database. For the search function, the criteria of the search is specified in a search filter. The search filter typically is a Boolean expression that consists of qualifiers including attribute name, attribute value and Boolean operators like AND, OR and NOT. Users can use the filter to perform complex search operations. One filter syntax is defined in RFC 2254.

[0009] LDAP thus provides the capability for directory information to be efficiently queried or updated. It offers a rich set of searching capabilities with which users can put together complex queries to get desired information from a backing store. Increasingly, it has become desirable to use a relational database for storing LDAP directory data. Representative database implementations include DB/2, Oracle, Sybase, Informix and the like. As is well known, Structured Query Language (SQL) is the standard language used to access such databases.

[0010] Many security systems are moving their databases to LDAP with the expectation that they can share common attributes, such as unique identifiers. A unique identifier is an identifier code (e.g., a number with many digits) that is guaranteed to be unique within the database of a security system. Unique identifiers are used to facilitate access control decisions. When an administrator adds a user or group to the security system, the security system typically generates a unique identifier or verifies that a unique identifier supplied by the administrator is unique, stores the unique identifier in the security system database, and protects the unique identifier so that it can never be modified.

[0011] LDAP, however, does not provide any mechanism to generate, verify, and protect a unique identifier. Therefore, each security system must store its own set of unique identifiers on LDAP, protect these unique identifiers so they cannot be modified, and take elaborate precautions to ensure that LDAP users do not attempt to fool the system by creating their own unique identifier information. The present invention overcomes this deficiency of the prior art.

[0012] The present invention defines a trusted process for use with a hierarchical directory service such as LDAP for enabling different security systems to store and retrieve unique identifiers that are shared or common to the entire directory. The trusted process allows LDAP users to store and to retrieve unique identifiers on LDAP using standard LDAP interfaces. It also allows security systems to share unique identifier information. The trusted process generates or verifies a unique identifier, guarantees the uniqueness of a unique identifier within the entire directory (rather than just within a single security system), and guarantees that any unique identifier returned to an LDAP user is a trusted unique identifier.

[0013] According to one aspect of the invention, a computer-implemented method is provided for configuring a unique identifier that may be shared by a plurality of users of a hierarchical directory such as LDAP. The method begins by intercepting a call from the LDAP administrator to a unique identifier attribute. The method then verifies that any unique identifier specified in the call is unique to the directory. If the call does not include a unique identifier, one is generated. Upon verification or generation of the unique identifier, as the case may be, the unique identifier is stored in a trusted unique identifier attribute of an entry of an object class in the directory. An access control is then set on the entry so that it cannot be modified. Although the unique identifier is actually stored in the trusted unique identifier attribute, the users of the unique identifier are notified that the unique identifier can be retrieved by making LDAP calls to the unique identifier attribute.

[0014] According to another aspect of the invention, a computer-implemented method is also provided for managing calls to the unique identifier attribute. When such calls are made, they are intercepted and then processed to retrieve the unique identifier from the trusted unique identifier attribute. In particular, the routine first verifies that a trusted process created an entry of a given object class that contains the trusted unique identifier attribute. Upon verification, the unique identifier is retrieved from the trusted unique identifier attribute (as opposed to the unique identifier attribute) and returned to the calling entity.

[0015] The present invention may be implemented in a computer program product useable in an LDAP directory service. The product comprises object class that contains a trusted unique identifier attribute used to store a unique identifier, and a trusted process. The trusted process includes code for creating a child entry of the object class, code for storing the unique identifier in the trusted unique identifier attribute, code for setting an access control on the child entry so that the child entry cannot be modified, and code for intercepting calls to a unique identifier attribute and processing such calls using the trusted unique identifier attribute.

[0016] The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects and features should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the preferred embodiment.

[0017] For a more complete understanding of the present invention and the advantages thereof, reference should be made to the following Detailed Description taken in connection with the accompanying drawings in which:

[0018] FIG. 1 is a representative LDAP directory service implementation;

[0019] FIG. 2 is a simplified LDAP directory;

[0020] FIG. 3 is a flowchart of an LDAP directory session;

[0021] FIG. 4 is a representative LDAP directory service implementation having a relational database backing store;

[0022] FIG. 5 illustrates a trusted process and how it is used according to the present invention;

[0023] FIG. 6 illustrates a portion of the LDAP directory showing the uniqueID attribute and trustedUniqueIDValue attribute of the present invention;

[0024] FIG. 7 illustrates how the trusted process of the present invention processes an LDAP call to write to a uniqueID attribute; and

[0025] FIG. 8 illustrates how the trusted process processes an LDAP call to retrieve a uniqueID attribute.

[0026] A block diagram of a representative LDAP directory service in which the present invention may be implemented is shown in FIG. 1. As is well-known, LDAP is the lightweight directory access protocol, and this protocol has been implemented in the prior art, e.g., as either a front end to the X.500 directory service, or as a standalone directory service. According to the protocol, a client machine 10 makes a TCP/IP connection to an LDAP server 12, sends requests and receives responses. LDAP server 12 supports a directory 21 as illustrated in a simplified form in FIG. 2. Each of the client and server machines further include a directory runtime component 25 for implementing the directory service operations as will be described below. The directory 21 is based on the concept of an “entry” 27, which contains information about some object (e.g., a person). Entries are composed of attributes 29, which have a type and one or more values. Each attribute 29 has a particular syntax that determines what kinds of values are allowed in the attribute (e.g., ASCII characters, .jpeg file, etc.) and how these values are constrained during a particular directory operation. Entries are stored in a given table (e.g., ldap_entry) that includes entry IDs, parent IDs, a create and last modified timestamp, together with the complete entry in string format. Each attribute has an associated attribute table.

[0027] The directory tree is organized in a predetermined manner, with each entry uniquely named relative to its sibling entries by a “relative distinguished name” (RDN). An RDN comprises at least one distinguished attribute value from the entry and, at most, one value from each attribute is used in the RDN. According to the protocol, a globally unique name for an entry, referred to as a “distinguished name” (DN), comprises a concatenation of the RDN sequence from a given entry to the tree root.

[0028] The LDAP search can be applied to a single entry (a base level search), an entry's children (a one level search), or an entire subtree (a subtree search). Thus, the scope supported by LDAP search are: base, one level and subtree. LDAP does not support search for arbitrary tree levels and path enumeration.

[0029] LDAP includes an application programming interface (API), as described in “The C LDAP Application Program Interface”, IETF Working Draft, Jul. 29, 1997, which is incorporated herein by reference. An application on a given client machine uses the LDAP API to effect a directory service “session” according to the flowchart of FIG. 3. At step 40, an LDAP session with a default LDAP server is initialized. At step 42, an API function ldap_init( ) returns a handle to the client, and this handle may allow multiple connections to be open at one time. At step 44, the client authenticates to the LDAP server using, for example, an API ldap_bind( ) function. At step 46, one or more LDAP operations are performed. For example, the API function ldap_search( ) may be used to perform a given directory search. At step 48, the LDAP server returns the results of the directory search, e.g., one or more database elements that meet the search criteria. The session is then closed at step 50 with the API ldap_unbind( ) function then being used to close the connection.

[0030] It may be desirable to store LDAP directory data in a backing store. FIG. 4 illustrates a representative LDAP directory service implementation that uses a relational database management system (RDBMS) for this purpose. This system merely illustrates a possible LDAP directory service in which the present invention may be implemented. One of ordinary skill should appreciate, however, that the invention is not limited to an LDAP directory service provided with a DB/2 backing store. The principles of the present invention may be practiced in other types of directory services (e.g., X.500) and using other relational database management systems (e.g., Oracle, Sybase, Informix, and the like) as the backing store.

[0031] In FIG. 4, an LDAP client 34 can connect to a number of networked databases 38a-38nthrough an LDAP server 36. The databases 38a-38ncontain the directory information. However, from the user's perspective, the LDAP server 36 stores all the information without knowing the database 38 in which the data is actually located. With this configuration, the LDAP server 36 is freed from managing the physical data storage and is able to retrieve information from multiple database servers 38 which work together to form a huge data storage.

[0032] The present invention is now described. To simplify the description, the following assumes that no existing security databases need to be migrated to LDAP and that unique identifiers need to be configured only for a relatively small number of people. Of course, this is not a limitation of the present invention.

[0033] According to the present invention, the directory service is augmented with a trusted process that is used to store and retrieve unique identifiers. The process is “trusted” in the sense that the developers of such code have adhered to stringent security standards in developing the code. The process allows LDAP users to store and retrieve unique identifiers on LDAP using standard LDAP interfaces. It also allows security systems to share unique identifier information. The trusted process functions generally to create or verify a unique identifier, to guarantee the uniqueness of a unique identifier within the entire directory, and guarantees that any unique identifier returned to an LDAP user is a trusted unique identifier.

[0034] To define the trusted process, the present invention preferably makes use of two features in the LDAP Version 3 protocol. The first feature makes it possible for a developer to provide LDAP backend code that will process an attribute defined by the developer. To this end, a developer defines an LDAP uniqueID attribute and then installs and configures LDAP backend code (referred to as a trusted process) that will process the uniqueID attribute. The second feature makes it possible to obtain the identity of the creator of an LDAP entry. The trusted process determines whether the LDAP entry storing the actual unique identifier value is a trusted entry (an entry that was created by itself or another trusted process) or an untrusted entry (an entry created by some other identity). These features of the invention will now be described in detail.

[0035] With reference now to FIG. 5, the trusted process developer begins by providing the LDAP administrator (or other entity) with LDAP backend code, referred to herein as a “trusted process” 100. As will be seen, the trusted process 100 is responsible for processing all LDAP calls to a uniqueID attribute. The trusted process developer also provides the LDAP administrator with a file (e.g., an LDIF file) defining two attributes 102 and 104, and one object class 106. In particular, attribute 102 is referred to herein as uniqueID, and attribute 104 is referred to as trustedUniqueIDValue. From the point of view of the LDAP user, uniqueID attribute 102 stores the unique identifier. However, as will be seen, all LDAP calls to this attribute are processed by the trusted process 100. The trusted process 100 actually stores the unique identifier in the trustedUniqueIDValue attribute 104 of a child entry 108 (an entry residing under the entry with the uniqueID attribute). The child entry 108 is trusted only if it was created by a trusted process 100. When the trusted process creates the child entry 108, it sets the access control lists (ACLs) on this entry so that they entry cannot be modified. According to the invention, the trustedUniqueIDValue attribute 104 (and not the uniqueID attribute) is used by the trusted process 100 to store and retrieve the unique identifier. It resides in an entry that is created by a trusted process, that contains the trustedUniqueID object class 106, and that resides under the entry containing the uniqueID attribute 102. The trustedUniqueID object class 106 is used to create the child entry (the entry under the entry with the uniqueID attribute 102) that contains the trustedUniqueIDValue attribute 104.

[0036] The LDAP administrator installs the trusted process and LDIF file that were provided to the administrator by the trusted process developer. The administrator may decide on a common place in the schema to configure the uniqueID attribute. For example, the administrator may decide to configure the uniqueID attribute for each person in the entry representing the person, although this is not a requirement of the invention. The LDAP administrator also configures the uniqueID attribute 102 for each person in the enterprise. To configure the uniqueID attribute, the administrator issues a standard LDAP call to the uniqueID attribute and optionally specifies a unique identifier value. The trusted process intercepts the call and processes it as follows (and as illustrated in FIG. 7). If the caller (namely, the administrator) specified a unique identifier, the trusted process verifies that it is unique with the directory; otherwise, the process generates a unique identifier that is unique with LDAP. It then creates a child entry (an entry under the entry with the uniqueID attribute) that is of object class trustedUniqueID. It then stores the unique identifier in the trustedUniqueIDValue attribute of the child entry and sets the ACLs on the child entry so that the entry cannot be modified.

[0037] FIG. 6 illustrates a portion 105 of the directory and, in particular, the uniqueID attribute 102, which is what the LDAP user uses to access the unique identifier. The portion 107 of the directory illustrates that the trusted process actually stores and retrieves the unique identifier using the trustedUniqueIDValue attribute 104. As described above, this entry is created by the trusted process, and ACLs are set on this entry so that the entry cannot be modified.

[0038] The LDAP administrator then informs the developers of all security systems in the enterprise that they need to retrieve unique identifiers from the uniqueID attribute and that they can use standard LDAP calls to retrieve this attribute. The LDAP administrator also ensures the developers that the uniqueID attribute is processed by a trusted process and guaranteed to store a unique identifier values that are unique within the enterprise.

[0039] The developer of each security system in the enterprise modifies the security system so that it retrieves unique identifier values from the uniqueID attributes configured by the LDAP administrator. To retrieve a unique identifier, the developer issues a standard LDAP call to the uniqueID attribute. The trusted process intercepts this call and processes it as follows (and as described in FIG. 8). It finds a child entry that is of object class trustedUniqueID and that contains a trustedUniqueIDValue attribute. It then verifies the creator of the child entry was a trusted process and retrieves the unique identifer value from the trustedUniqueIDValue attribute. This value is then returned to the caller.

[0040] FIG. 7 illustrates how the trusted process processes an LDAP call to write to a uniqueID attribute. The routine begins at step 110 when the trusted process gets the LDAP call. At step 112, the trusted process tests to determine whether the caller specified a unique identifier. If not, the routine branches to step 114, wherein the trusted process generates a unique identifier that is unique within the directory (i.e. no trustedUniqueIDValue attribute exists on the directory with the same unique identifier value). If, however, the outcome of the test at step 112 is positive, the trusted process executes a test at step 116 to verify whether this unique identifier is unique within the directory. If not, the trusted process returns an error message to the caller at step 118. Following step 114, or if the outcome of the test at step 116 is positive, the routine continues at step 120 with the trusted process creating a child entry of the TrustedUniqueID object class. At step 122, the trusted process stores the unique identifier in the trustedUniqueIDValue attribute of the child entry. At step 124, the trusted process sets the access control lists (ACLs) on the child entry so that the entry cannot be modified. The routine then returns successful at step 126 to complete the process.

[0041] FIG. 8 is a flowchart illustrating how the trusted process processes an LDAP call to retrieve a uniqueID attribute. The routine begins at step 130 when then trusted process gets the LDAP call. At step 132, trusted process performs a test to determine whether a child entry exists that is of the type TrustedUniqueID. If not, an error is returned at step 134. If, however, the outcome of the test at step 132 is positive, the routine continues at step 136 wherein the trusted process determines whether the creator of the child entry was a trusted process. If the outcome of the test at step 136 is negative, an error message is returned at step 134. If, however, the creator of the child entry was a trusted process, the routine continues at step 138 wherein the trusted process tests whether the child entry contains a trustedUniqueIDValue attribute. If not, an error message is returned at step 134. If, however, the outcome of the test at step 138 is positive, the trusted process continues at step 140 to return the value of trustedUniqueIDValue to the caller. This completes the processing.

[0042] The present invention provides numerous advantages. It enables security systems to port their databases to LDAP without having to store their own sets of unique identifiers. With the present invention, security systems can share unique identifiers or other common attributes of interest. For example, assume that there are two security systems, one based on The Open Group DCE and a second system based on IBM® Policy Director. Using the invention, the LDAP administrator would configure one set of unique identifiers for people and groups, and these unique identifiers would be used by both security systems. More specifically, the administrator would create a unique identifier for each person by configuring a uniqueID attribute in the person entry. The administrator would create a uniqueID for each group by configuring a uniqueID attribute in the group entry. In both cases, the unique identifier actually would be stored in the trustedUniqueIDValue attribute of the child entry as described above. DCE and Policy Director, as the case may be, would then used the uniqueID in the person entry to retrieve a unique identifier for a person, and the unique identifier in the group entry to retrieve the unique identifier of a group. As a consequence, one of ordinary skill will appreciate that each individual security systems need no longer store its own set of unique identifiers and/or protect such identifiers against modification as has been required in the prior art. Rather, the trusted process enables the creation and storage of “global” unique identifiers that can be used across the entire directory service.

[0043] Moreover, although the preferred embodiment has been described in the context of creating and using global unique identifiers in LDAP, the inventive technique should be broadly construed to extend to any hierarchical directory such as in an X.500 directory service or hereinafter-developed LDAP implementations. Generalizing, the present invention is may be implemented in conjunction with any higher level directory structure in which information is spread out over a set of tables.

[0044] The trusted process may be implemented as a plug-in to the LDAP server. Alternatively, the process may comprise part of the LDAP server code. It also may be provided as an application service. Generalizing, the trusted process is a set of instructions (e.g., computer program code) in a code module resident in or downloadable to the random access memory of a computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network.

[0045] In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.

[0046] One of ordinary skill in the art should also appreciate that the “unique identifier” as described in this application and as recited in the claims should be construed broadly to cover any sensitive information stored on LDAP that may require the intervention of a trusted process for storing/retrieving the information.

[0047] Having thus described our invention, what we claim as new and desire to secure by letters patent is set forth in the following claims: