Method for storing sparse hierarchical data in a relational database

• US 6,438,549 B1
• Filed: 12/03/1998
• Issued: 08/20/2002
• Est. Priority Date: 12/03/1998
• Status: Expired due to Term

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Aldred, Barry Keith, Stokes, Ellen J., Shi, Shaw-Ben, Byrne, Debora Jean
• Primary Examiner(s): RONES, CHARLES
• Application Number:
  US09/204,920
• Time in Patent Office: 1,356 Days
• Field of Search: 707/2, 707/3, 707/5, 707/9, 707/103, 707/4, 707/102
• US Class Current: 707/640
• CPC Class Codes: G06F 16/284 Relational databases
• CPC Class Codes: Y10S 707/954 Relational
• CPC Class Codes: Y10S 707/956 Hierarchical
• CPC Class Codes: Y10S 707/99932 Access augmentation or optimizing
• CPC Class Codes: Y10S 707/99939 Privileged access
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface

Abstract

A method for securing sparse access control list (ACL) data in a relational database used as a backing store for a hierarchical-based directory service. The sparse ACL data is secured in a plurality of tables. An owner table stores data objects with explicitly set ACLs. A propagation table stores data on whether individual ACLs are inherited by descendant objects. A permissions table stores data regarding permissions which a user may perform on an object. A source table stores data for a set of ancestor objects having respective ACLs for each of a set of descendant objects. Preferably, the tables are stored in the relational database together with the objects. For a given object, data in the tables is used to determine the given object'"'"'s entry owner and ACL. The inventive technique has particular applicability in a Lightweight Directory Access Protocol (LDAP) directory service having a relational database as a backing store.

Claims

1. A relational database, comprising:

a first table storing data on objects with explicitly set ACLs;

a second table storing data on whether individual ACLs art inherited by descendant objects;

a third table storing data regarding permissions which a user may perform on an object; and

a fourth table storing data for a set of ancestor objects having respective ACLs for each of a set of descendant objects.

2. A computer program product in a computer-readable medium for use in a sparse access control list (ACL) mechanism wherein entries without an explicitly set ACL inherit an ACL set for an ancestor entry, comprising;

means for storing in a first table data on objects with explicitly set ACLs,

means for storing in a second table data on whether individual ACLs are inherited by descendant objects;

means for storing in a third table data regarding permissions which a user may perform on an object;

means for storing in a fourth table data for a set of ancestor objects having respective ACLs for each of a set of descendant objects; and

means for using data in the first, second, third and fourth tables for a given object, to determine the given object'"'"'s entry owner and ACL.

3. In a sparse access control list (ACL) mechanism wherein entries without an explicitly set ACL inherit ACL set for an ancestor entry, a method for securing ACL data in a relational database, comprising the steps of;

storing in a first table data on objects with explicitly set ACLs;

storing in a second table data on whether individual ACLs are inherited by descendant objects;

storing in a first table data regarding permissions which a user may perform on an object;

storing in a fourth table data for a set of ancestor objects having respective ACLs for each of a set of descendant objects; and

for a given object, using data in the first, second, third and fourth tables to determine the given object'"'"'s entry owner and ACL.

4. The method as described in claim 3 wherein the first, second, third and fourth tables are stored in the relational database together with the objects.

5. The method as described in claim 4 wherein the given object'"'"'s entry owner is determined by using owner source data in the fourth table and locating corresponding owner information in the first table.

6. The method as described in claim 3 wherein the given entry'"'"'s ACL is determined by using ACL source data in the fourth table and locating corresponding ACL propagation and entry information in the second and third tables.

7. The method as described in claim 3 wherein the relational database is used as a backing store for a Lightweight Directory Access Protocol (LEAP) directory service.

8. The method as described in claim 3 wherein the relational database is DB/2.

9. In a directory service having a directory organized as a naming hierarchy, the hierarchy including a plurality of entries each represented by a unique identifier, the improvement comprising:

a relational database management system having a backing store for storing directory data;

a sparse access control list (ACL) mechanism wherein entries without an explicitly set ACL inherit and ACL set for an ancestor entry; and

means for securing ACL data in the backing store in a plurality of tables, including;

a first table storing data on objects with explicitly set ACLs;

a second table storing data on whether individual ACLs are inherited by descendent objects;

a third table storing data regarding permissions which a user may perform on an object; and

a fourth table storing data for a set of ancestor objects having respective ACLs for each of a set of descendent objects, wherein, for a given object, data in the first, second, third and fourth tables is useful for determining the given object'"'"'s entry owner and ACL.

10. In the directory service as described in claim 9 wherein the directory is compliant with the Lightweight Directory Access Protocol (LDAP).

11. In the directory service as described in claim 10 wherein the relational database management system is DB/2.

12. A directory service, comprising:

a directory organized as a naming hierarchy having a plurality of entries each represented by a unique identifier;

a relational database management system having a backing store for storing directory data;

a sparse access control list (ACL) mechanism wherein entries without an explicitly set ACL inherent and ACL set for an ancestor entry; and

means for securing ACL data in the backing store in a plurality of tables, including;

a first table storing data on objects with explicitly set ACLs;

a second table storing data on whether individual ACLs are inherited by descendant objects;

a third table storing data permissions which a user may perform on an object; and

a fourth table storing data for a set of ancestor objects having respective ACLs for each of a set of descendent objects, wherein, for a given object, data in the first, second, third and fourth tables is useful for determining the given object'"'"'s entry owner and ACL.

13. The directory service as described in claim 12 wherein the directory is compliant with the Lightweight Directory Access Protocol (LDAP).

14. The directory service as described in claim 12 wherein the relational database management system is DB/2.