Hierarchy-based secured document repository

Techniques are provided for implementing and using a hierarchy-based secured document repository. The invention, the repository allows each user access to documents based on the position(s) held by the user in the hierarchy of a company. In one embodiment, the repository includes data that reflects the hierarchy of a company (“hierarchy data”), where the hierarchy includes nodes and relationships between nodes. The repository also includes user-to-node mapping data that maps users to one or more nodes, and document-to-node mapping data that maps documents to nodes. An access mechanism is provided that determines which document a user is able to access based on the hierarchy data, the user-to-node mapping data, and the document-to-node mapping data. In one embodiment, a user is allowed to access only those documents that are (1) mapped to the same node as the user, or (2) mapped to nodes that are below (relative to the hierarchy) any of the nodes to which the user is mapped.

FIELD OF THE INVENTION

The present invention relates to document repositories and, more specifically, to a hierarchy-based secured document repository.

BACKGROUND OF THE INVENTION

A large percentage of hard-copy documents being produced today are generated from corresponding electronic documents. As with their hard-copy counterparts, electronic documents may include confidential, proprietary and/or secret information. Consequently, it is as important to be able to limit access to the electronic documents of a company, as it is to limit access to the hard-copy documents of the company.

The specific members of the company that should have access to a document will vary based on the content of the document and the policy of the company. Frequently, the position that one holds in a company dictates the documents to that the individual is allowed to access. For example, a company executive may have access to information that an office clerk is not allowed to access. An individual's relative level within the company may not be the only factor that dictates the documents to which the individual has access. For example, a relatively lower-level clerk in the financial department of a company may have rights to access financial information to which a relatively higher-level employee in the research department has no access rights.

Various approaches have been used to restrict access to electronic documents. One common approach is to use password protected shared directories. Using this approach, all documents that are to be shared among a particular group are placed in a shared directory, and the directory is password protected. The password to access the directory is then communicated to the members of the group. When a user tries to access the directory, the file system or operating system software that manages the directory requests the password from the user. If the user enters the correct password, then the user is allowed to access the folder and the entire contents thereof. Without the correct password, the user is not allowed to access the documents in the protected folder.

The password-protected shared folder approach works well in situations where there are a few, well-defined groups. However, in larger organizations it may not be practical. For example, higher-level executives may need access to the documents shared among numerous disparate groups. It is not practical to require each of the executives to remember all of the relevant passwords. It becomes even less practical when, for security reasons, the passwords are changed periodically, or in response to the departure of any member of the group.

Based on the foregoing, it is clearly desirable to be able to share electronic documents among those allowed to access them, while at the same time providing a convenient and secure system that protects the documents from those who are not authorized to access them.

SUMMARY OF THE INVENTION

Techniques are provided for implementing and using a hierarchy-based secured document repository. According to one aspect of the invention, the repository allows each user access to documents based on the position(s) held by the user in the hierarchy of a company. In one embodiment, the repository includes:

(1) data that reflects the hierarchy of a company (“hierarchy data”), where the hierarchy includes nodes and relationships between nodes;

(2) user-to-node mapping data that maps users to one or more nodes; and

(3) document-to-node mapping data that maps documents to nodes.

An access mechanism is provided that determines which document a user is able to access based on the hierarchy data, the user-to-node mapping data, and the document-to-node mapping data. In one embodiment, a user is allowed to access only those documents that are (1) mapped to the same node as the user, or (2) mapped to nodes that are below (relative to the hierarchy) any of the nodes to which the user is mapped.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

System Overview

Referring toFIG. 1, it is a block diagram of a system100that includes a hierarchy-based secured document repository102, according to one embodiment of the invention. In the illustrated embodiment, the repository102resides on a storage device104. Storage device104generally represents any type or number of devices on which electronic information may be stored, including, for example, a set of magnetic disks.

Repository102stores a set of documents120. As used herein, the term “document” refers to any form of electronic data item. The nature of documents120may vary from implementation to implementation. For example, in one implementation, documents120may be electronic files created by word processing programs, graphics programs, and spreadsheet programs. In an alternative embodiment, documents120may be computer programs or sound files. The present invention is not limited to any particular type of document.

In the illustrated embodiment, repository102includes data that reflects the hierarchy of a company (hierarchy data106), where the hierarchy includes nodes and relationships between nodes. Repository102also includes user-to-node mapping data108that maps users to one or more nodes, and document-to-node mapping data110that maps documents to nodes.

System110also includes an access mechanism112through which users (114–118) access documents120stored in the repository102. Access mechanism112determines which of documents120a user is able to access based on the hierarchy data106, the user-to-node mapping data108, and the document-to-node mapping data110. In one embodiment, a user is allowed to access only those documents that are mapped to the same nodes as the user, or mapped to nodes that are below (relative to the hierarchy) the nodes to which the user is mapped.

Exemplary Mappings

Assume that a company (“company X”) is organized according to the hierarchy200illustrated inFIG. 2. Each node in the hierarchy corresponds to what is referred to herein as an “ORG-UNIT”. In general, an ORG-UNIT is a position, role, or group that has or may have distinct access privileges to the documents in repository102relative to the access privileges of other positions, roles and groups within an organization.

Referring toFIG. 2, a president ORG-UNIT202is at the top level of the hierarchy. Various vice-president ORG-UNITs204,206and208are at the level immediately under the president ORG-UNIT202. VP ORG-UNIT204is responsible for two departments, DEPT1and DEPT2. Thus, the ORG-UNITs DEPT1HEAD210and DEPT2HEAD212are under VP ORG-UNIT204. The ORG-UNIT of DEPT1EMPLOYEES214is below the ORG-UNIT of DEPT1HEAD210.

VP ORG-UNIT206is in charge of one department (DEPT3) and three ad hoc committees (AD HOC COMMITTEES218,220and222). The DEPT3HEAD ORG-UNIT216is below VP ORG-UNIT206, and the DEPT3EMPLOYEES ORG-UNIT224is below DEPT3HEAD216.

VP ORG-UNIT208is responsible for one department (DEPT4) that has three distinct groups. The DEPT4HEAD ORG-UNIT226is below VP ORG-UNIT208, and all of three groups of the department (DEPT4GROUP1228, DEPT4GROUP2230, DEPT4GROUP3232) are below the DEPT4HEAD ORG-UNIT226.

The company hierarchy200shown inFIG. 2, which is much simpler than the organizational hierarchy of most companies and organizations, is presented solely for the purpose of explanation. The invention is not limited to any particular type or structure of hierarchy. Further, an embodiment is described in which the hierarchy represents the relationship between ORG-UNITs within a company X. However, the present techniques may be used to secure the documents of any entity that has document access policies that correspond to a hierarchical structure. The term “organization” is used herein to refer to all such entities.

Referring toFIG. 3, it illustrates a node hierarchy300represented in the hierarchy data106within the repository102used by company X. In particular, each ORG-UNIT in the organization hierarchy200of company X has a corresponding node in the node hierarchy300. Hierarchy data106includes data that identifies the nodes, and data that identifies the relationship between the nodes.

The nature of hierarchy data106may vary from implementation to implementation. For example, in one embodiment, repository102is implemented in a relational database. In such an embodiment, a “hierarchy table” may be used to store the hierarchy data106, where each row of the hierarchy table corresponds to a node, and includes a field that identifies the parent node of that node. Instead of or in addition to storing parent node information, the row associated with a node may store child node information. Alternatively, a first table may be used to store rows that correspond to nodes, while a second table is used to store data indicating the parent-child relationships between the nodes. The present invention is not limited to any particular structure for storing the hierarchical data102.

Referring toFIG. 4, it illustrates a user-to-node mapping in which users within company X are mapped to the nodes of hierarchy300that correspond to the ORG-UNITs to which they belong. It should be noted that individual users may map to many nodes. Further, the nodes to which a user is mapped need not be part of the same branch in the hierarchy. For example, user418maps to DEPT1EMPLOYEES314and AD HOC COMMITTEE322.

Referring toFIG. 5, it illustrates a document-to-node mapping in which the documents120managed by repository102are mapped to the nodes of hierarchy300. According to one embodiment, each document is mapped to the lowest node that corresponds to an ORG-UNIT that is allowed to access the document. For example, if ORG-UNITS202,204and210are allowed access to a particular document, then that document would be mapped to the node corresponding to ORG-UNIT210.

If ORG-UNITS in different branches of the hierarchy are allowed access to a document, then the document is mapped to the lowest node, in each of those branches, that corresponds to an ORG-UNIT allowed to access the document. For example, if ORG-UNITS202,204,210,206and220are allowed access to a particular document, then that document would be mapped to the node corresponding to ORG-UNIT210and to the node corresponding to ORG-UNIT220.

In an alternative embodiment, documents are mapped to all nodes that correspond to ORG-UNITS allowed to access the documents. For example, if ORG-UNITS202,204,210,206and220are allowed access to a particular document, then that document would be mapped to the nodes corresponding to ORG-UNITS202,204,210,206and220.

In the illustrated mapping, DOC502is mapped to the PRESIDENT NODE302. DOC504is mapped to VP NODE304. DOC506is mapped to VP NODE306. DOC508is mapped to VP NODE308. DOC510is mapped to DEPT4HEAD326. DOC512is mapped to DEPT4GROUP1328. DOC514is mapped to DEPT2HEAD312and AD HOC COMMITTEE318. DOC516is mapped to DEPT4GROUP2330. DOC518is mapped to DEPT1EMPLOYEES314and AD HOC COMMITTEE316.

Exemplary Operation

With the hierarchy data106, the user-to-node mapping data108, and the document-to-node mapping data110established to reflect the relationships indicated inFIGS. 3,4and5, respectively, access mechanism112would operate as follows. When a user114attempts to access documents120in repository102, access mechanism112determines the identity of the user114. Access mechanism112may determine the identity of a user114using any one of a variety of techniques. The particular technique employed by access mechanism112may depend on a variety of factors including the implementation of access mechanism112.

For example, access mechanism112may detect the fingerprint of the user114, and compare the fingerprint with stored fingerprint data. Alternatively, access mechanism112may read a bar code from an identification card assigned to user114. In an embodiment in which repository102is implemented within a database, access mechanism112may simply determine the identity of user114based on the userid, or userid/password combination, that user114uses to log into the database server that manages repository102.

After the user has been identified, the access mechanism112inspects the user-to-node mapping to determine the nodes to which the user is mapped. For example, assume that user114corresponds to user data408. User data408maps to three nodes: VP NODE308, DEPT4HEAD326and AD HOC COMMITTEE318.

The nodes to which a user maps determines the documents within repository102that access mechanism112allows the user to access. According to one embodiment, access mechanism112allows a user to access all documents that are mapped to (1) any node to which the user is mapped, or (2) any node that resides below any node to which the user is mapped. To determine the nodes that reside below the nodes to which the user is mapped, the access mechanism112inspects the hierarchy data106. In the present example, the following nodes reside below VP NODE308: DEPT4HEAD326, DEPT4GROUP1328, DEPT4GROUP2330and DEPT4GROUP3332. The following nodes reside below DEPT4HEAD326: DEPT4GROUP1328, DEPT4GROUP2330and DEPT4GROUP3332. No nodes reside below AD HOC COMMITTEE318. Note that, in the present example, user114is not associated with any more nodes by virtue of being mapped to DEPT4HEAD326than those to which user114is already associated by virtue of being mapped to VP NODE308, which resides above DEPT4HEAD326in the node hierarchy300.

Based on the hierarchical data106and the user-to-node mapping108, access mechanism112determines that the user114associated with user data408is allowed access to documents associated with any of nodes VP NODE308, DEPT4HEAD326, DEPT4GROUP1328, DEPT4GROUP2330and DEPT4GROUP3332, AD HOC COMMITTEE318.

By inspecting the document-to-node mapping108, access mechanism112is able to identify the specific set of documents to which user114is allowed access. In the present example, DOCS508,510,512,514,516and518are mapped to one or more of the nodes associated with user data408. Consequently, access mechanism112allows user114to access those documents, and does not allow user114to access any other of documents DOC502–518.

The manner by which access mechanism112allows access may vary from implementation to implementation, and the present invention is not limited to any particular access technique. For example, in a relational database implementation of repository102, a database server may be configured to restrict all selections made in queries issued by user114in such a way as to only allow selection of the documents user114is allowed to see. Alternatively, user114may be presented with a file-system interface, where repository102appears as a directory or folder. When access mechanism112is invoked to display the contents of the folder, access mechanism112determines the documents that user114is allowed to see, and displays only those documents within the folder.

Regardless of what techniques are used by access mechanism112to restrict access to the documents, it is preferable to not only prevent a user from accessing documents to which the user is not allowed access, but also to prevent the user from learning of the existence of such documents. For example, rather than displaying a folder that lists all documents but only allows selection of some of them, it is preferred that access mechanism112cause the folder to display only the documents to which access is allowed.

Handling Modifications

Over time, the structures of most organizations change, as do the personnel, the roles assigned to individuals, and the documents used in those roles. The data maintained by repository102to determine who has access to which of documents120must by modified in response to such changes. Many changes involve minor modifications to the data, while other changes require more extensive modifications. According to one embodiment, modifications are handled as explained in greater detail hereafter.

If a user ceases to be part of the organization, then the user data associated with the user is deleted, as are all links from that user data to nodes.

If a user ceases to belong to an ORG-UNIT in the organization, then the link between the user data associated with that user and the node associated with that ORG-UNIT is deleted. For example, if user114ceases to act as the head of DEPT4, then the link between user data408and DEPT4HEAD326is deleted.

If a user is assigned to a new ORG-UNIT in the organization, then a link is added between the user data associated with that user and the node associated with that ORG-UNIT.

User-related modifications may be performed even when there is no change in ORG-UNIT membership. For example, even though a user is part of a particular ORG-UNIT, the user need not be granted the same access privileges as all other members of the ORG-UNIT. The access privileges of an ORG-UNIT may be denied to a member of an ORG-UNIT by not linking the user data for that member to the corresponding ORG-UNIT node in the user-to-node mapping. Similarly, access privileges of a user may be revoked by deleting the links between the user data for that user and one or more of the ORG-UNIT nodes in the user-to-node mapping.

If a document is deleted from repository102, then the links between that document and any nodes are deleted.

If persons in a particular ORG-UNIT are no longer allowed to access a document, then the link between that document and the node associated with that ORG-UNIT is deleted. If persons in higher ORG-UNITS in the same branch are still allowed to access the document, then a link is established between the document and the lowest node in that branch that corresponds to an ORG-UNIT that is still allowed to access the document. For example, assume that members of AD HOC COMMITTEE218are no longer allowed access to DOC514, but the person in VP ORG-UNIT206is still allowed access. Under these conditions, the link between DOC514and AD HOC COMMITTEE NODE318is deleted, and a new link between DOC514and VP NODE306is established.

If persons in a particular ORG-UNIT are allowed to access a document to which they previously were not allowed access, then a link is added between that document and the node associated with that ORG-UNIT. If a link already exists between the document and a node that is above that node, then that already-existing link may be deleted. For example, if DEPT4GROUP1is allowed to access DOC510, then a link is established between DOC510and DEPT4GROUP1328, and the link between DOC510and DEPT4HEAD326may be deleted.

If a new ORG-UNIT is created in the organizational hierarchy, then hierarchy data106is updated to include (1) a node associated with that ORG-UNIT, and (2) the relationship between that node and existing nodes.

If an ORG-UNIT is moved from one position to another in the organizational hierarchy, then the hierarchy data106is updated by adding a link between the corresponding node and its new parent, and deleting the link between the corresponding node and its old parent.

If an ORG-UNIT is dissolved, then the node associated with that ORG-UNIT is deleted. The nodes associated with all ORG-UNITS below the node of the dissolved ORG-UNIT are also deleted unless moved to other locations in the organization hierarchy. When a node is deleted, all user-to-node links and document-to-node links to that node are also deleted. If the deletion of a document-to-node link deletes the last document-to-node link from a document, then, according to one embodiment, the document is added to an “orphaned document pool”. The administrator of repository102may then manually perform reassignments of the documents in the orphaned document pool to existing nodes.

In an alternative embodiment, when the last document-to-node link associated with a document is deleted, a new link is automatically established between the document and the lowest surviving node in the same branch as the deleted node. For example, assume that a document is linked to DEPT3EMPLOYEES324. If DEPT3is dissolved, then nodes DEPT3HEAD316and DEPT3EMPLOYEES324will be deleted. The lowest remaining node in the branch to which DEPT3EMPLOYEES324belongs is VP NODE306. Thus, the document can be automatically be assigned to VP NODE306by creating a document-to-node link between the document and VP NODE306.

According to one embodiment of the invention, techniques are provided for automatically synchronizing the hierarchy data106with a newly submitted set of hierarchy information. According to one embodiment, an administrator of repository102submits a set of data that indicates the modified hierarchy of a company. In response to receipt of the modified hierarchy data, the hierarchy data106, user-to-node mapping data108and document-to-node mapping data110are modified. According to one embodiment, the synchronization is performed in a sequence that minimizes the number of orphaned documents that result from the re-organization. In particular, when a node no longer appears at the same location in the newly presented hierarchy as it does in the hierarchy data106, it is only processed as a deleted node after confirming that it is not merely a moved node.

In such an embodiment, it is first determined which nodes in the modified hierarchy data are new relative to the existing hierarchy data106. Then it is determined which nodes have moved in the new hierarchy data relative to the existing hierarchy data106. Finally, after all of the new and moved nodes have been processed, it is determined which nodes have been deleted from the modified hierarchy data that currently exist in the hierarchy data106. When performing the synchronization, it is particularly useful to perform inserts of new nodes before moves because some of the moved nodes may have to be placed below the newly inserted nodes. Moves are performed before deletions to ensure that moved nodes are not erroneously processed as deleted nodes.

According to one embodiment, during the insert phase of the synchronization, the hierarchy300is traversed using a traversal technique that ensures that each node is processed exactly once. Various traversal techniques are well known. During the traversal of hierarchy300, it is important that parent nodes are processed before their children. For example, DEPT3HEAD316should be inserted into hierarchy300before DEPT3EMPLOYEES324so that child nodes can be linked to parent nodes as part of the node insertion process. Therefore, according to one embodiment, a traversal technique is employed that (1) ensures that each node is processed exactly once, and (2) ensures that parent nodes are processed before their children. Various known traversal techniques satisfy these requirements, including left-most tree transversal, right-most tree transversal, and top-to-bottom level-by-level transversal.

In an embodiment that is implemented in a relational database that supports SQL, the insert phase of the synchronization operation may be executed in response to submitting a hierarchical query to the database server. In such an embodiment, an efficient way to ensure that parent nodes are added to the hierarchy before child nodes is to use an insert statement that leverages the power of hierarchical queries. The following statement guarantees that parent nodes are inserted before their children by returning data in hierarchical order instead of by rowid order.

In this example SQL statement the FSP_NODE table contains the current state of the organizational hierarchy and the FSP_HIERARCHY_SOURCE contains the new structure for the organizational hierarchy.

Attribute Matching

In the embodiments described above, a user's ability to see and access the documents120in the repository102is based entirely on the hierarchy data106, the user-to-node mapping data108and the document-to-node mapping data110. However, the hierarchy-based security provided by this technique may be combined with other security techniques that restrict access based on other factors. Thus, while access mechanism112restricts access based on the hierarchy data106, the user-to-node mapping data108and the document-to-node mapping data110, access mechanism112need not restrict access based exclusively on these factors.

For example, in one embodiment, security attributes are assigned to users and to documents. The values of the security attributes may include for example: management, generic, finance, etc. In such an embodiment, access mechanism112may be configured to determine which documents120a user is allowed to access based on a combination of the hierarchical techniques described herein and a matching operation between the security attributes assigned to the users and to the documents120.

In one embodiment, the attribute-based security further restricts the hierarchy-based security. For example, a user that is mapped to an ORG-UNIT node may be denied access to a document that is mapped to that same ORG-UNIT node if the document has the “management” attribute value and the user does not.

In another embodiment, the attribute-based security is able to override the hierarchy-based security, at least in certain circumstances. For example, a user that has the “management” attribute value may be allowed access to a document that also has the “management” attribute value even though the user does not map to any node at or above the nodes to which the document is mapped.

Implementations

The techniques described herein may be implemented in a variety of environments using a variety of techniques. For example, the techniques may be incorporated into a file system, instead of or in addition to any other file security mechanisms provided thereby. For example, a file system may employ these techniques in addition to or instead of password protected directories.

According to one embodiment, the repository is implemented in a database that is made available to users over a network, such as the Internet. In such an embodiment, the user may access the database server by using a browser to send a request to a web server. The web server may, in turn, communicate the request to the database server. Initially, the user may be asked to log in to the database in order for the access mechanism112to determine the identity of the user. If the user has already logged in before, then the log in process may be handled transparent to the user through the use of cookies or similar mechanisms.

In response to the user's request, the access mechanism112, which may be implemented within the database server or as a layer between the user and the database server, identifies which documents the user is allowed to access using the techniques described above. The access mechanism112then causes the web server to communicate to the user a web page with information about the documents that the user is allowed to access. The user may then access those documents through controls or links provided on the web page.

According to one embodiment, management of repository102is performed over the Internet using a web browser interface. In particular, upon verifying that a user has management authority over repository102, the access mechanism112may send one or more web pages with controls that allow the user to: submit documents (and document-to-node assignment information), submit user-to-node assignments, and submit information about changes in the organization hierarchy. The document-to-node assignment information may be separate from the documents themselves, or may be metadata attached to or embedded in the documents.

Hardware Overview

FIG. 6is a block diagram that illustrates a computer system600upon which an embodiment of the invention may be implemented. Computer system600includes a bus602or other communication mechanism for communicating information, and a processor604coupled with bus602for processing information. Computer system600also includes a main memory606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus602for storing information and instructions to be executed by processor604. Main memory606also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor604. Computer system600further includes a read only memory (ROM)608or other static storage device coupled to bus602for storing static information and instructions for processor604. A storage device610, such as a magnetic disk or optical disk, is provided and coupled to bus602for storing information and instructions.

The invention is related to the use of computer system600for implementing the techniques described herein. According to one embodiment of the invention, those techniques are performed by computer system600in response to processor604executing one or more sequences of one or more instructions contained in main memory606. Such instructions may be read into main memory606from another computer-readable medium, such as storage device610. Execution of the sequences of instructions contained in main memory606causes processor604to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

The received code may be executed by processor604as it is received, and/or stored in storage device610, or other non-volatile storage for later execution. In this manner, computer system600may obtain application code in the form of a carrier wave.