|Publication number||US20080104029 A1|
|Application number||US 11/591,975|
|Publication date||May 1, 2008|
|Filing date||Nov 1, 2006|
|Priority date||Nov 1, 2006|
|Also published as||US7647307|
|Publication number||11591975, 591975, US 2008/0104029 A1, US 2008/104029 A1, US 20080104029 A1, US 20080104029A1, US 2008104029 A1, US 2008104029A1, US-A1-20080104029, US-A1-2008104029, US2008/0104029A1, US2008/104029A1, US20080104029 A1, US20080104029A1, US2008104029 A1, US2008104029A1|
|Inventors||Peter A. Rowley, Steven W. Parkinson|
|Original Assignee||Rowley Peter A, Parkinson Steven W|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (2), Classifications (11), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application is related to co-filed U.S. patent application Ser. No. ______ entitled “Extension Of Organizational Chart Dynamic Group Lists Based On LDAP Lookups” (attorney docket number 5220.P014), Ser. No. ______ entitled “Deriving Cross-Relational Relationships From LDAP Source Data” (attorney docket number 5220.P015), Ser. No. ______ entitled “Nested Queries with Index” (attorney docket number 5220.P016), and Ser. No. ______ entitled “Dynamic Views based on LDAP” (attorney docket number 5220.P018), all of which are assigned to the assignee of the present application.
This invention relates generally to network directory services, and more particularly to Lightweight Directory Access Protocol directories.
Lightweight Directory Access Protocol (LDAP) is a networking protocol for TCP/IP network directory services. An LDAP directory typically is represented as a hierarchical tree of entries, each of which consists of a set of named attributes with values. Each entry has a unique identifier known as a Distinguished Name (DN), which consists of a set of attributes and the DN of its parent entry, if any. The set of attributes is referred to as the entry's Relative Distinguished Name (RDN). Each attribute consists of a “name:value” pair and some attributes may be multivalued. Thus, the entry for Jane Smith who works for John Doe in the Sample company may be represented as a string:
dn: cn=Jane Smith, dc=sample, dc=com
manager: cn=John Doe, dc=sample, dc=com
where dn is the name of the entry, “cn=Jane Smth” is the entry's RDN and “dc=sample, dc=com” is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like “cn” for common name, “dc” for domain component, and “mail” for e-mail address. The attributes for a DN are defined as objects in an LDAP schema. A Directory Information Tree (DIT) defines the logical structure of the hierarchy
Each LDAP server in a network commonly stores a directory subtree rooted at a specific entry, e.g. “dc=sample, dc=com” and will return results of queries on that subtree to the requesting client. An LDAP server may also hold references to other LDAP servers, so that a query on the “ou=Engineering, dc=sample, dc=com” would cause the server to return to the client a reference to another LDAP server that stores that part of the directory tree. Alternatively, an LDAP server may be configured to pass the query onto the appropriate server and then return the result to the client.
Values for virtual reverse attributes are generated for distinguished name entries in a lightweight directory access protocol directory by navigating through a list of distinguished name values for an input virtual recursive attribute. An attribute list of the values for the virtual reverse attributes may be cached or indexed. In another aspect, the list of distinguished name values for the input virtual recursive attribute is generated.
In the following detailed description of embodiments of the invention, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.
A system level overview of the operation of an embodiment of the invention is described with reference to
The queries are processed by an LDAP service module 111. A view service module 109 generates and maintains views that filter entries retrieved by a query to the LDAP directory 107. The filtered results may be presented to the client 105 in a graphical representation. The directory server 101 also includes a virtual attributes subsystem 113, which creates and maintains virtual attributes for DN entries in the LDAP directory 107 through a set of virtual attribute service provider modules 115. Each virtual attribute service provider module is responsible for at least one of the virtual attributes and may generate a virtual attribute index 117 to aid in searching the virtual attributes. In one embodiment, each entry in a virtual attribute index 117 contains a unique value for the corresponding attribute and a list of DN values that are associated with that unique value.
When the directory server 101 is configured, each virtual attribute service provider module, or plugin, 115 registers, with the server 101, the virtual attributes it will compute and a list of attributes that it uses to compute the virtual attributes, i.e., the “parent” attributes of the computed attributes, which may be virtual as well. Typically the server 101 maintains one list per virtual attribute. The list of dependency attributes is used to generate a logical “dependency chain” structure 203, 211 for the virtual attributes as shown in
The resulting dependency chains may be used at run time to determine whether a change made to the LDAP directory 107 requires that one or more of the virtual indices 201 need to be updated. The directory server 101 locates the virtual attribute to be changed in the appropriate index and adds each of its parent attributes (i.e., the attributes from which it is computed) to a list of affected attributes by following the dependency chain until the top (root) node of the dependency chain 203 is reached, at which point, all indices to be updated are on the list. It will be appreciated that any member of a dependency chain may be a member of a different dependency chain so that a single dependency chain may fan out into multiple dependency chains, each of which the server 101 will follow to the root node.
For entry attribute modification after configuration, the directory server 101 accesses each index in the list in turn and updates the value set for the attribute to the new value set calculated by the appropriate plugin 115. The update operation may be performed in real time while blocking a writer query and access to the entry itself in order to make the operation atomic.
Virtual attribute configuration entry modification may affect the values for many attributes over many entries. Beginning at the “leaves” of the dependency chain, each index is queried for the value or values of the attribute contained in the configuration before the change, producing a candidate list of possibly affected entries. The directory server 101 accesses each entry in the index that is also in the list of affected entries and updates the value set for the attribute to the new value set as calculated by the appropriate plugin 115.
In one embodiment, all affected indices in the tree might be taken offline to avoid incorrect query results. An alternative embodiment blocks queries from using the indices until the operation is done. In still another embodiment, the blocking may be configurable and depend on such parameters as the number of indices affected, entries affected, time spent before taking offline versus blocking.
A special case is the virtual attribute that is computed as a result of an attribute value pair that the target entry contains, which is a DN that points to another entry containing the values as illustrated in
Another, but related special case, is when the relational attribute is recursively relational, i.e., an attribute X is determined by the value of attribute X (or even some other recursive attribute) in the pointed-to entry plus the value of that entry's DN, which itself may be determined by the value of attribute X in its pointed-to entry. In this case, the change methodology would need to process each entry in the chain. This processing can be made faster using virtual recursive attributes as described below in conjunction with
Turning now to
It will be appreciated that the method 320 may be executed on each DN in the directory. In such an embodiment, each entry in the virtual recursive attribute index contains a unique value for the virtual recursive attribute and a list of DN values that are associated with the index. This index can then be used to process standard nested queries more quickly.
A method 340 in
It will be appreciated that method 340 generates the inverse of the virtual attributes generated by the method of 320 so the virtual indirect recursive attributes may also be referred to as virtual reverse attributes. Together, the sets of virtual attributes generated by methods 320, 340 can be envisioned as forming a bidirectional graph of the portions of the directory for which the virtual attributes have been generated. Thus, the indices of virtual recursive and reverse attributes may be used to more quickly process nested queries, such as “Give me the names of everyone in John Doe's organization.” In addition, the indices of virtual recursive and reverse attributes may be pregenerated for common nested queries to enable faster response times.
While the virtual recursive and virtual reverse attributes have been described in terms of their use in responding to nested queries, they also can be used to define dynamic groups based on some common group attribute. Examples of such use include calendar groups, and access control lists (ACLs). Other servers also may use the virtual attributes. For example, a mail server could resolve a mailing list attribute into a list of email addresses by querying the LDAP server. Assume the value of the mailing list attribute is email@example.com. If the user firstname.lastname@example.org exists in the LDAP directory, the mail server would request a list the email addresses of all of Jane Smith's direct reports from the LDAP server, i.e., those defined by the virtual attribute “mydirectreports” with the value “janesmith” as explained above in conjunction with
The term “virtual attribute” is used herein to mean any attribute that is calculated from one or more LDAP attributes, either real or virtual, as described in conjunction with
Turning now to
The embodiment of
Furthermore, the method 400 is invoked by the directory server when one of the values for the attribute changes. If the value is deleted (block 411), the method 400 searches the appropriate subview list to determine if there is only one DN entry in the list (block 415). If so, the subview is deleted because there will be no more DN entries with the original value (block 417). If not, the corresponding DN entry is deleted from the subview list (block 419).
If a new unique value is added (block 421), the method 400 adds the value to the list of unique values for the corresponding attribute (block 423) and creates a subview for the new unique value (block 425).
Is some cases, a new attribute may be defined after initialization. Similar to the process represented at blocks 405 and 407 for adding attributes during initialization, the method 400 will generate a list of unique values for the new attribute (block 427) and the appropriate subviews (block 429). For example, if a new attribute is defined that specifies filtering on the location attribute, the method 400 will generate a list of unique location values and create a subview for each location in the list.
The dynamic views created by method 400 may be used to generate cross-relational views as described next in conjunction with
Method 500 receives the selected DN (block 501) and searches the subview lists (block 503 until block 511). The DN entries for each subview list are examined (block 505). If any DN entry matches the selected DN (block 507), the subview is added to a list (block 509). When all subview lists have been examined (block 511), a list of view(s) corresponding to the sublists are returned for display to the client (block 513). It will be appreciated that the hierarchical tree view subsequently may be created using the subview list that corresponds to a selected one of the entries in the view list as described previously.
In addition, it is fairly common to derive organizational charts from the DN entries in an LDAP directory, in which each level in an organizational chart corresponds to a real DN attribute. However, the LDAP administrator may define organizational chart levels in the schema as associated with dynamic views to provide a dynamic organizational chart as illustrated in
In practice, the methods 300, 320, 340, 400, 500 and 600 may constitute one or more programs made up of machine-executable instructions. Describing the method with reference to the flowcharts in
The following description of
The web server 9 is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the World Wide Web and is coupled to the Internet. Optionally, the web server 9 can be part of an ISP which provides access to the Internet for client systems. The web server 9 is shown coupled to the server computer system 11 which itself is coupled to web content 10, which can be considered a form of a media database. It will be appreciated that while two computer systems 9 and 11 are shown in
Client computer systems 21, 25, 35, and 37 can each, with the appropriate web browsing software, view HTML pages provided by the web server 9. The ISP 5 provides Internet connectivity to the client computer system 21 through the modem interface 23 which can be considered part of the client computer system 21. The client computer system can be a personal computer system, a network computer, a Web TV system, a handheld device, or other such computer system. Similarly, the ISP 7 provides Internet connectivity for client systems 25, 35, and 37, although as shown in
Alternatively, as well-known, a server computer system 43 can be directly coupled to the LAN 33 through a network interface 45 to provide files 47 and other services to the clients 35, 37, without the need to connect to the Internet through the gateway system 31. Furthermore, any combination of client systems 21, 25, 35, 37 may be connected together in a peer-to-peer network using LAN 33, Internet 3 or a combination as a communications medium. The communications medium also encompasses a carrier wave that encodes a data signal for transmission. Generally, a peer-to-peer network distributes data across a network of multiple machines for storage and retrieval without the use of a central server or servers. Thus, each peer network node may incorporate the functions of both the client and the server described above.
It will be appreciated that the computer system 51 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an input/output (I/O) bus for the peripherals and one that directly connects the processor 55 and the memory 59 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used with the embodiments of the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 59 for execution by the processor 55. A Web TV system, which is known in the art, is also considered to be a computer system according to the embodiments of the present invention, but it may lack some of the features shown in
It will also be appreciated that the computer system 51 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. The file management system is typically stored in the non-volatile storage 65 and causes the processor 55 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 65.
Although the invention as been described with reference to specific embodiments illustrated herein, this description is not intended to be construed in a limiting sense. It will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiments shown and is deemed to lie within the scope of the invention.
In addition, one of skill will recognize that references to lists, indices, and like, are intended to cover all types of data structures that utilize logical pointers to locate entries in an LDAP directory.
Accordingly, this application is intended to cover any such adaptations or variations of the present invention. Therefore, it is manifestly intended that this invention be limited only by the following claims and equivalents thereof.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8782085 *||Apr 10, 2007||Jul 15, 2014||Apertio Limited||Variant entries in network data repositories|
|US9112873||Apr 10, 2007||Aug 18, 2015||Apertio Limited||Alias hiding in network data repositories|
|U.S. Classification||1/1, 707/999.003|
|Cooperative Classification||Y10S707/99933, H04L29/12084, H04L29/12132, H04L61/1523, H04L61/1552|
|European Classification||G06F17/30Z1T, H04L61/15E, H04L29/12A2E|
|Nov 1, 2006||AS||Assignment|
Owner name: RED HAT, INC., NORTH CAROLINA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROWLEY, PETER A.;PARKINSON, STEVE W.;REEL/FRAME:018494/0711
Effective date: 20061027
|Jul 12, 2013||FPAY||Fee payment|
Year of fee payment: 4