JP2003280990A - Document processing device and computer program for managing document - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce the maintenance work for a change of organization (group) needed conventionally because the access right for shared documents are managed only with user ID or group ID. <P>SOLUTION: An electronic data management server 1 maintains an access control list (ACL) relating user attribute information (post information of the organization, a range of administrative authority or the like) with a kind of access (for example, reference/reedition/update/deletion) for every document and controls the access for the document by the ACL for the request from clients 5A, 5B to manage the access right. By referring the ACL by the user attribute information, the user attribute is associated with the access right directly and the burden of the review of the constitution of the group, conventionally needed for reorganization, is reduced. <P>COPYRIGHT: (C)2004,JPO

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a document processing apparatus (system) having an electronic data server function that allows a plurality of users to use shared electronic data, such as a document DB utilization system and a file server. In particular, the access control list (ACL) is directly referred to by the primary information relating to the user attribute information (for example, the post information of the organization, the range of job authority, etc.), and the access set for the target document (electronic data). The present invention relates to the document processing device (system) capable of managing the access right for permitting.

[0002]

2. Description of the Related Art Conventionally, accumulated documents (electronic data)
In a document management device (system) or file server that allows multiple users to access the stored documents, the access right to the stored documents is restricted by the users so that no inconvenience occurs for the multiple users who use the shared documents that are shared. The data is properly maintained and managed. For example, in Japanese Patent Laid-Open No. 9-218827, an access right list in which an authentication system name, a user name, and an access right are set is given to each electronic document (data), and when the electronic document is opened, the user is identified in the authentication system. There has been proposed an electronic document management apparatus configured to authenticate the user and recognize the access right of the authenticated user using the access right list. Note that this example differs depending on the management environment by authenticating the user by an authentication system specified by the user (listed in the access right list) in order to configure a system adapted to a plurality of user management environments. We are trying to deal with the case where the authentication system is adopted. Generally, the setting of the access right to the electronic document which is the operation target is performed by directly using the user's name or ID, as in Japanese Patent Laid-Open No. 9-218827, or on the directory service like the user. It is known that the name or ID of a group that has been set is used. The directory service described above provides a list of registered authenticateable users and a user search service. By the way, in the case of Microsoft Windows (registered trademark), Active Directory
The function is provided by a service called
A server that implements a protocol generally called LDAP (LightWait Directory Access Protocol) provides both authentication service and directory service.

By the way, when the access right is set by the group ID, the group can include a plurality of users or other groups, and if the access right is set for the group. , The user belonging to the group is interpreted as having the access right, and enables access to the stored electronic document. When setting access rights by assigning a user's access right list for each electronic document, the number of access rights set by grouping multiple users when using the group-based method, compared to the case of only users By operating the group by associating it with the organization to which it belongs and posts (positions etc.) on the organization, it is possible to separate the access rights to be actually set from the members of the organization, which are often fluid. There are advantages such as.
Focusing on the advantages of, if the organization configuration is changed and the users who have access rights are changed, it is possible to respond by modifying the members of the group according to the actual organizational change. It is not necessary to change the access rights that are set for the stored documents of each one.

[0004]

However, in the case of the group correspondence method, the primary information regarding the organizational structure is the user's affiliation information and attribute information set in the directory service, and the members constituting the group are separately classified by the user. Needs to register the settings, and if there is an organizational change, it will be corrected accordingly. If you do not modify and register as a member of the group, you will not get access. Therefore, in the case of adopting the group corresponding method for the purpose of the above advantages, it is a fact that the review of the group configuration necessary when the organization is changed is a heavy burden. In many cases, each user can create the group structure relatively freely, and since the degree of freedom is high, it is generally difficult to automatically reflect the change. The present invention has been made in view of the above-described problems of the conventional technique in the document processing system such as an electronic data server that enables a plurality of users to access a stored document (electronic data). , Access right management that can reduce the maintenance work when changing the organization (group), which was necessary because the access right to the stored shared document was managed only by the user ID and group ID. An object of the present invention is to provide a document processing device (system) having an electronic data server function to be performed and a computer program for configuring the document processing device.

[0005]

According to a first aspect of the present invention, there is provided a document processing apparatus having a document management unit for placing a document under a folder and managing the document according to the access right set for the document and the folder. Then, the document management unit holds in advance access right setting information indicating the access right set for the document and the folder in association with the user attribute information, and accesses the instruction content indicated in the user's access request. The document processing apparatus is characterized in that the right is checked according to the right setting information and the access right is permitted according to the matching setting condition.

According to a second aspect of the present invention, in the document processing apparatus according to the first aspect, the document management unit, when the user attribute information is post information of an organization having a hierarchical structure,
It is characterized in that when the access right is granted, the access right set in relation to the post positioned higher than the post as an attribute of the user who made the access request is also allowed. .

According to a third aspect of the invention, in the document processing apparatus according to the first or second aspect, the attribute information of the user in the access right setting information is a combination of a plurality of attribute information. is there.

According to a fourth aspect of the present invention, in the document processing apparatus according to any one of the first to third aspects, the access right setting information is set for a combination of user information and user attribute information, a document and a folder. It is characterized in that it shows a relationship with the access right that has been set.

A fifth aspect of the present invention is a computer program for placing a document under a folder and managing the document according to the access right set for the document and the folder. Step of acquiring user attribute information and access type information based on the access request of the user, and the acquired user attribute information and access right type are set for the document and folder in association with the user attribute information prepared in advance. It is a computer program for executing each processing step of checking by the access right setting information indicating the access right and allowing the access right that matches the check result.

[0010]

BEST MODE FOR CARRYING OUT THE INVENTION The document processing apparatus of the present invention will be described based on the following embodiments shown in the accompanying drawings. FIG. 1 shows the outline of the configuration of a document processing apparatus (system) according to the embodiment of the present invention. As shown in FIG. 1, the document processing system of this example includes an electronic data management server 1 having a storage 11, an authentication server 2, a directory server 3 having a user information DB (database) 31, and a plurality of clients. A system is configured by connecting the computers 5A and 5B as constituent elements via a network. The electronic data management server 1 holds electronic data (for example, documents) shared by a plurality of users in the storage 11, operates the electronic data in response to access requests from the plurality of client computers 5A, 5B, and stores the electronic data for the clients. Acts as a server. Each time the electronic data management server 1 accesses the shared electronic data, it checks whether or not it is an operation by an appropriate user. For this purpose, the authentication server 2 and the directory server 3 are used. The authentication server 2, or the directory server 3 depending on the configuration, authenticates the user indicated by the access request from the client computers 5A and 5B, and if the authentication is successful, the authentication information stored in the user information DB 31 is displayed. Notify the electronic data management server 1. If the authentication fails, no operation is permitted. or,
The authentication server 2 and the directory server 3 are synchronized with each other regarding the management information of the user, and the two may be integrated and configured as one server. The check in the electronic data management server 1 is the AC set in the authentication information acquired from the authentication server and the electronic data to be operated.
By matching L (access control list), the possible operation (access) type set in the ACL is obtained. Also, as a result of this collation, the consistency between the obtained operation type and the operation type requested by the client is checked, and access control by the operation type that matches (matches) is permitted,
The target electronic data in the storage 11 can be operated. Although FIG. 1 shows the document processing system of the embodiment constructed on the network, it is implemented as a stand-alone document processing apparatus by installing a computer program for realizing necessary functions in a workstation. It is also possible to do so.

An ACL (access control list) will be described. The ACL is a list that defines who is allowed to perform what operation for each operation target such as a file or a data folder. In the prior art, it is a method of determining the range of access right by a user or a group. FIG. 2 exemplifies a conventional ACL. In FIG. 2, three entries are registered. Each entry has a user ID or group ID, information that identifies whether the entry represents a user or a group, the type of operations that the user or group can perform,
That is, information indicating whether or not the operation type consisting of reference / revision / update / deletion is permitted is instructed. Next, the authentication information will be described. The authentication information is information prepared for authenticating the user who has made the access request, and is stored in the user information DB 31 under the control of the directory server 3. One of the authentication information is a group definition, an example of which is shown in FIG. In this example, a group named “Plan 2 group” is defined, and the group ID and the composition of members are described. Another piece of authentication information is user-defined, an example of which is shown in FIG. In this example, "tana
A user named "ka" is defined, and its ID, telephone number, e-mail address, and authority for work (in Fig. 4, "Post
Code: 6 ”is shown as an example in which the range of job authority is converted to data) and other user attributes are described. The authentication information (FIGS. 3 and 4) used in the present embodiment is basically the same as that in the conventional example.

In the present embodiment, the type of operation (access right type) that can be performed on the target electronic data is defined by the user attribute directly in the ACL, and the group change which is necessary when only the conventional user ID or group ID is used. It is intended to reduce maintenance work at the time. An example of the ACL based on the user attribute of this example is shown in FIG. The difference from the conventional example (Fig. 2) is that instead of specifying the user by using the user or group ID, the range taken by the user attribute, that is, here, Post Code <4 and Post depending on the range of authority for work. Cod
The point is that the user is specified by specifying each entry of e <6.

FIG. 6 is an example of user attributes having a hierarchical structure. Users who are managed by the directory service,
Groups and other resources may be defined based on the hierarchical structure shown in FIG. The hierarchical structure of a directory is often used to represent the organization of an organization. In Fig. 6, the user'tanaka 'is in the hierarchy'o = ab
c''ou = ppu, o = abc 'belongs to the post (node) called'ou = p2g, ou = ppu, o = abc'. Another ACL example according to the embodiment of the present invention is for a user attribute having a hierarchical structure as illustrated in FIG. Figure 7
The ACL is illustrated. Here, the specified condition is that the post (node) in the hierarchical structure is dn = 'ou = p2g, ou =
The user is specified by specifying each entry as ppu, o = abc 'and dn =' ou = ppu, o = abc '. FIG. 8 illustrates the range of access rights shown in FIG. 7. The access right set for the specified post affects all users belonging to the hierarchy below the post. That is, dn = 'ou = p2g, ou = ppu, o = abc'
Access right (reference / revision) set for the entry
Indicates that the access right (reference) set in the entry of dn = 'ou = ppu, o = abc' extends to the range Z3 shown in FIG. 8 and extends to the range Z2 shown in FIG. The access right (reference / revision / update / deletion) set for the entry extends to the range Z1 shown in FIG.

Another example of an ACL according to an embodiment of the present invention is for a combination of user attributes. FIG. 9 illustrates the ACL. It indicates that multiple user attribute conditions are also written in the attribute condition section and connected by the binary operator'and 'so that only users who simultaneously satisfy multiple user attribute conditions have the set access right. . Here, as shown in the first record of FIG.
The specified condition is defined as a combination of a hierarchical node and a range of authority for duties, that is, "dn = 'ou = p2g, ou
The user is specified by specifying an entry as "= ppu, o = abc '" and "Post Code <6". Another example of the ACL according to the embodiment of the present invention is
This is a combination of multiple access right setting methods.
FIG. 10 illustrates the ACL. By having the user attribute condition and the user or group ID together in the attribute condition section and connecting them with the binary operator'and ', only the users who simultaneously satisfy the conditions according to the multiple access right setting methods have the access right. It shows that you do. Here, as shown in the first record of FIG. 10, the specified condition is "ObjectClass = 'Person'" and "id = 26.
4 ”, the user is specified by specifying the entry.

Next, an embodiment relating to the access right control processing by the shared data management server in the above-mentioned document processing system will be described below. The following "Embodiment 1", "Embodiment 2", "Embodiment 3", and "Embodiment 4" are based on the access control list (ACL) of FIG. 5, FIG. 7, FIG. 9, and FIG. By performing access right control, it is possible to directly perform target operations on the target electronic data according to user attributes, and the organization or group that was necessary when access right control was performed only with conventional user IDs or group IDs. It is possible to reduce the maintenance work when the configuration is changed. [First Embodiment] FIG. 11 is an access right control processing flow according to the first embodiment (by the ACL illustrated in FIG. 5). The part surrounded by (A) in FIG. 11 is the ACL.
Is equivalent to the processing for one record of. Referring to FIG.
Client computer 5A (5B) to storage 1
A flow of the access right control processing of the present example performed by the electronic data management server 1 every time there is a request for access to the target electronic data stored in 1 will be described. First, the authentication server 2 authenticates whether or not the access request is made by an appropriate user. As a procedure therefor, it is checked whether or not the authentication procedure has been completed (S11).
The authentication procedure is performed by connecting to the authentication server 2 (S12).
The authentication procedure is performed by checking whether the user information (or user attribute information) described in the access request is registered in the user information DB 31 of the directory server 3. If the user information (or user attribute information) cannot be confirmed and the authentication fails (S13-NO), the access request is rejected and no operation is permitted. On the other hand, if the authentication is successful (S13-YES), as the next step, the user attribute information held therein is acquired from the authentication server 2 (which may be the directory server 3 depending on the configuration) and the authentication information ( It is held as (FIG. 4) (S14).

Next, by comparing the authentication information acquired from the authentication server 2 with the ACL of the operation object, it is checked whether the operation of the access request can be performed. Specifically, since each record of the ACL (FIG. 5) set for each operation target is compared with the authentication information, one record of the ACL is extracted (S15),
Furthermore, the attribute condition of the record (in this example, the user attribute value included in the authentication information as the attribute condition, that is, Post Code
The permission range for the job authority such as <4 is set) and the user attribute information described in the authentication information authenticated in step S13 is extracted (S16). If both are compared and the attribute condition of ACL does not exist in the authentication information (S1
7-NO), or if the attribute value is not within the ACL attribute condition range (Post Code <4) even if the attribute exists (S18-NO),
Since the collation is unsuccessful, it is confirmed that all records have been checked (S20). If not, the procedure returns to step S15 to collate the next one record. On the other hand, the ACL attribute condition exists in the authentication information (S17-
YES), or if the attribute value is within the range of the ACL attribute condition (S18-YES), the collation is established, so the access permission information on the ACL record is extracted, and revision / update / deletion is permitted other than reference. If so, they are added to the possible access operation types (S19). Note that each record in ACL is independent. When there are multiple types of access permissions as in the example, a user attribute that satisfies the conditions of multiple records on the ACL can obtain both access permissions. After confirming the completion of all records (S20-YES), the above-mentioned ACL is used to determine whether or not the access operation type (access right) indicated in the access request content of the user can be permitted.
A check is made according to the type of access operation permitted in association with the user attribute confirmed by (S21). As a result of this check, if the user's access request content does not match the permission condition set in the ACL (S21-NO), the access request is rejected. On the other hand, if the user's access request content matches the permission condition set in the ACL (S21-YE
S), enabling the access operation type according to the request (S)
22). In this way, the access right management function is realized by comparing the access permission with the operation instructed by the user, executing only the operation that is possible, and not executing the operation that is not permitted.

[Second Embodiment] FIG. 12 relates to the access right control processing flow of the second embodiment (by the ACL illustrated in FIG. 7). In the present embodiment, the portion corresponding to the processing for one record of ACL enclosed by (A) in FIG. 11 is shown in FIG.
It is implemented by replacing with the flow shown in
The same process flow as in FIG. 11 is executed except for the process for the records. The flow of the access right control process of this example will be described with reference to FIG. In the first step in the flow of FIG. 12, whether or not the access request is made by an appropriate user is authenticated by the user information (or user attribute information) written in the access request. When the user is authenticated, the user attribute information including the “user attribute having a hierarchical structure” held therein is acquired from the authentication server 2 and held as the authentication information (see FIG. 11). After that, the processing step of FIG. 12 for comparing each record of the ACL (FIG. 7) set for each operation target with the authentication information is started. First, one record of ACL is taken out, and the attribute condition of that record (in this example,
The user attribute having the hierarchical structure included in the authentication information as the attribute condition, that is, the permission range for the condition such as dn = 'ou = p2g, ou = ppu, o = abc' is set) and the authenticated authentication information. The retrieved user attribute information is retrieved (S3
1). When both are compared and the attribute condition of the ACL does not exist in the authentication information (S32-NO), or even if the attribute condition is not an attribute having a hierarchical structure (S33-NO), the attribute condition set in this ACL If it is not within the range (S38-NO), the collation is unsuccessful, and the check of the record is finished.

On the other hand, when the attribute condition of ACL exists in the authentication information (S32-YES) and the attribute has an hierarchical structure (S33-YES), the hierarchical structure obtained from the authentication information as user attribute information. The attribute value having is processed to obtain a list of nodes on the hierarchy to which the user belongs (S34). For example, when user management having a hierarchical structure as shown in FIG. 6 is performed, the user'cn = tanaka, ou = p2g, ou = ppu, o = abc 'analyzes the attribute value to 'o = ab
c''ou = ppu, o = abc 'It can be seen that it belongs to the post (node) called'ou = p2g, ou = ppu, o = abc'. Next, the attribute condition of the ACL record and the post (node) name obtained by processing the authentication information are compared (S35). If the collation is unsuccessful (S36-NO), the check of the record ends. If the verification is successful (S3
6-YES), the access permission information on the ACL record is taken out, and when revision / update / deletion other than reference is permitted, these are added to the possible access operation types (S3).
7). Specifically, the ACL record (Fig. 7) and the above ~
To compare. ACL second record'ou = p2g, ou = ppu, o
Since = abc 'matches with, and'ou = ppu, o = abc' in the third record matches with, it is determined that this user has the access right for “reference / revision”. As shown in FIG. 8, when the access right to each node is set, the setting becomes valid for all users belonging to the lower order. The ACL attribute condition exists in the authentication information (S32-
YES), even if the attribute is not an attribute having a hierarchical structure (S33-NO), if the condition is met (S38-YES), for example, id = 264 (FIG. 7), the ACL is followed. The access right is set (S37).

[Third Embodiment] FIG. 13 relates to the access right control processing flow of the third embodiment (by the ACL illustrated in FIG. 9). Note that, in this embodiment, the portion corresponding to the processing for one record of ACL enclosed by (A) in FIG. 11 is shown in FIG.
It is implemented by replacing with the flow shown in
The same process flow as in FIG. 11 is executed except for the process for the records. In addition, the portion surrounded by (B) in FIG. 13 shows a portion corresponding to processing for one condition by dividing the combination condition of ACL attributes. The flow of the access right control process of this example will be described with reference to FIG. In the first step in the flow of FIG. 13, whether or not the access request is made by an appropriate user is authenticated by the user information (or user attribute information) described in the access request. When the user is authenticated, the user attribute information held by the authentication server 2 and composed of a combination of a plurality of types is acquired and held as the authentication information (see FIG. 11). After that, the process step of FIG. 13 for comparing each record of the ACL (FIG. 9) set for each operation object with the authentication information is entered. First, one record of the ACL is taken out, and the attributes described therein are recorded. The condition data is parsed to extract one condition (S41). In order to interpret the general compound condition described as the attribute condition in the ACL and check the conformity, it is necessary to parse the conditional statement, but here, as shown in FIG. 9, it is relatively simple. 'A =
Separate'A = a 'and'B = b' from the condition of'a and B = b ',
An example of a method in which both conditions are determined and then the two are integrated is shown. As a general attribute condition, a complex product that uses a logical product (AND), a logical sum (OR), a negation (NOT), an equal sign (=), an inequality sign (<,>), and combinations thereof as operators. Conditions can also be defined. In that case, you need to do a little more complicated parsing than the one illustrated here.

At the beginning of the check processing (part (B) in FIG. 13) for one condition obtained by parsing the attribute condition described in one record of ACL, one analyzed condition of the record (this example Then, a user attribute having a hierarchical structure included in the authentication information as an attribute condition, that is, dn = 'ou = p2g, ou = pp
u, o = abc ', and the rank of job authority, that is, P
Since the permitted range for the combination of conditions such as ost Code <6 is set, the user attribute information described in the authenticated condition and the authenticated attribute information is extracted (S42). When both are compared and the attribute condition of ACL does not exist in the authentication information (S43-NO), the collation process is not performed and the collation is unsuccessful, and the process skips to step S48. When the attribute condition of ACL exists in the authentication information (S
43-YES), the process branches depending on whether the attribute has a hierarchical structure or not, so that confirmation is made (S44). When the attribute is an attribute having a hierarchical structure (S44-YES), the attribute value having a hierarchical structure obtained as the user attribute information from the authentication information is processed to obtain a list of nodes on the hierarchical layer to which the user belongs (S45). . This process is step 3 in FIG.
The processing is the same as that of No. 4, and the above description is referred to. Then AC
The attribute condition of the L record is compared with the post (node) name obtained by processing the authentication information, and it is determined whether or not the collation is established (S46), and the process proceeds to the next step S48. On the other hand, the condition (in this example, the rank of the job authority) when the attribute does not have a hierarchical structure is collated, and it is determined whether or not the collation is established (S47), and the process proceeds to the next step S48. Next, it is determined whether or not the conditions are satisfied by receiving the collation result obtained above and considering the operator indicating the combination condition of the ACL attributes (S48). When the condition is rejected as the determination result (S49-YES), the check of the record is finished. If the conditions are not rejected as the determination result of step S48 (S49-NO), it is confirmed whether all the conditions of the combination of ACL attributes have been checked (S5).
0), if all conditions are not checked (S50-N
O), and returns to step S41 to check the next condition. Note that the process of step S49 ends the check only when it is confirmed that the condition is not satisfied, and does not reject in other undefined states. If all the conditions have been checked without rejecting the conditions (S50-YES), the ACL attribute combination conditions will be satisfied, so the access permission information on the ACL record is extracted and revised other than for reference. If the / update / delete is permitted, they are added to the possible access operation types (S51), and the check for the one record is completed.

[Fourth Embodiment] FIG. 14 relates to the access right control processing flow of the fourth embodiment (by the ACL illustrated in FIG. 10). In the present embodiment, the portion corresponding to the processing for one record of ACL enclosed by (A) in FIG. 11 is shown in FIG.
ACL flow is performed by replacing the flow shown in 4
The same process flow as in FIG. 11 is executed except for the process for one record. Further, step S64 in FIG.
The portion surrounded by (B), that is, the portion corresponding to the processing for one condition by dividing the combination condition of ACL attributes is shown. With reference to FIG. 14, a flow of the access right control process of this example will be described. In the previous step of entering the flow of FIG. 14, it is determined whether or not the access request is made by an appropriate user, and the user information (or user attribute information) described in the access request.
Authenticate by. When authenticated, this example is intended to ensure that only users who simultaneously satisfy the conditions of multiple access right setting methods have the set access rights. Attribute information is acquired from the authentication server 2 and held as authentication information (see FIG. 11). After that, the process steps (S62 to S64) of FIG. 14 for comparing each record of the ACL (FIG. 10) set for each operation object with the authentication information are entered. First, one record of the ACL is taken out and stored in that. The described attribute condition data is parsed to extract one condition (S61). In order to interpret the general compound condition described as an attribute condition in ACL and check the conformity, it is necessary to parse the conditional statement, but here,
As shown in FIG. 9, 'A = a'and'B = b 'are separated from the relatively simple'A = a and B = b' condition, each condition is judged, and finally both are judged. An example of integration method is given. As a general attribute condition, AND (AND) as an operator,
Complex conditions using logical sum (OR), negation (NOT), equal sign (=), inequality sign (<,>), and combinations thereof can also be defined. In that case, you need to do a little more complicated parsing than the one illustrated here.

In this example, since a condition for specifying a group is added to the attribute conditions combined in the "third embodiment", the attribute condition described in one record of the ACL is obtained by parsing 3 Check processing for the types of conditions is required. Therefore, in order to branch the check processing for these three kinds of conditions, first, it is confirmed whether the one condition extracted in step 61 is a condition that can specify a group, and if it is a group (S62-YES), The directory server 3 is searched, and the user ID included in the authentication information is
It is determined whether or not the member is included in the members of the corresponding group (S63). On the other hand, if the one condition extracted in step 61 is not a condition that can specify a group (S62-N
O), the process of part (B) of FIG. 13 described in the "third embodiment", that is, the process of dividing the combination condition of the user attributes of the ACL is performed (S64). In this way, the check processing for the three types of conditions is performed in a branched manner, and the determination results (S63, S46, S47) obtained respectively, that is, the result of success / failure of the matching of the attribute conditions are received, and the ACL attribute Considering the operator indicating the combination condition, it is determined whether or not the conditions according to the plurality of access right setting methods are satisfied (S6).
5). When the condition is rejected as the determination result (S66-Y
ES), the check of the record ends. Step S
When the condition is not rejected as the determination result of S65 (S66)
-NO), check whether all the conditions of the combination of ACL attributes have been checked (S67), and if all the conditions have not been checked (S67-NO), step to check the next condition. Return to S61. Note that step S65
In the process of, the check of the record is finished only when it is confirmed that the condition is not satisfied, and it is not rejected in other undefined states. If all the conditions have been checked without rejecting the conditions (S67-YES), the ACL attribute combination conditions will be satisfied, so access permission information on the ACL record is extracted and revised other than for reference. If the / update / delete is permitted, they are added to the possible access operation types (S68), and the check for the one record is completed.

The access right control processing shown in each of the above "first embodiment" to "fourth embodiment" creates a computer program for executing each processing step shown in the exemplified flow, and executes the computer program to manage the computer program. It can be implemented by using it as an operation control program in a computer that constitutes a server (electronic data management server 1 in the system example of FIG. 1). A computer constituting the document management server (electronic data management server 1) has a storage unit (not shown) under the control of a built-in CPU (not shown) for executing a program (software) for executing a processing procedure required for the server function. ) Is stored in the storage medium and the process according to the program is executed, but created as a part of the program to execute the access right control process illustrated in each of the “first embodiment” to the “fourth embodiment”. Realize the desired access right control using a program.

[0024]

Advantageous Effects of Invention (1) The effect document management unit (electronic data management server) corresponding to the invention of claim 1 documents user attribute information (post information of organization, range of job authority, etc.) and type of access right. Since an access control list (ACL) associated with each item is stored and the ACL is referenced by the user attribute information for access requests, the user attribute can be directly linked to the access right. Even when the organization (group) is inaccessible when it is changed because it is managed only by the group ID, backup is possible, and the maintenance work when changing the organization (group), which is indispensable It is possible to reduce the burden of reviewing the group composition). (2) Effect corresponding to the invention of claim 2 In addition to the effect of (1) above, when the access right setting is made for post information of an organization having a hierarchical structure, the access right set to the upper level post Since it is also allowed, it is easier to grant access rights to members who belong to the organization. (3) Effect corresponding to the invention of claim 3 In addition to the effects of (1) and (2) above, the attribute information of the user in the access right setting information is a combination of a plurality of attribute information. The degree can be increased. That is, the access right setting using the group that has been conventionally performed has a great degree of freedom,
Although it is difficult to realize the same setting only by the inventions of claims 1 and 2, the invention of claim 3 facilitates effective use of user attributes, and provides flexible access according to data security. You can set the right.

(4) Effect corresponding to the invention of claim 4 In addition to the effects of (1) to (3), the access right setting information of ACL is a combination of user information and user attribute information, so that it is more flexible. It is possible to manage access rights that are highly manageable and easy to manage. That is, the access right setting by the group is effective when setting the access right for a set of persons who are unrelated to the user attributes managed by the directory server. In this case, the organization (group) change is not Since access rights that are completely unrelated to each other can be set, it becomes possible to construct a more flexible and easy-to-manage access right management system by using both of them together. (5) By installing a program for executing each processing step described in claim 5 in a computer constituting an effect document management unit (electronic data management server) corresponding to the invention of claim 5, It is possible to easily realize the effect of (1).

[Brief description of drawings]

FIG. 1 shows an outline of a configuration of a document processing apparatus (system) according to an embodiment of the present invention.

[Figure 2] Conventional ACL (access control list)
For example:

FIG. 3 shows an example of authentication information (group definition) stored in a user information DB.

FIG. 4 shows an example of authentication information (user definition) stored in a user information DB.

FIG. 5 shows an example (first embodiment) of an ACL according to the present invention.

FIG. 6 shows an example of user attributes having a hierarchical structure.

FIG. 7 shows an example (second embodiment) of an ACL according to the present invention.

FIG. 8 is a diagram illustrating a range of access rights according to the ACL of FIG.

FIG. 9 shows an example (third embodiment) of an ACL according to the present invention.

FIG. 10 shows an example of an ACL (Embodiment 4) according to the present invention.

FIG. 11 shows a flowchart of an access right control process (first embodiment) according to the present invention.

FIG. 12 shows a flowchart of an access right control process (second embodiment) according to the present invention.

FIG. 13 shows a flowchart of an access right control process (third embodiment) according to the present invention.

FIG. 14 shows a flowchart of an access right control process (fourth embodiment) according to the present invention.

[Explanation of symbols]

1 ... Electronic data management server 2 ... Authentication server,
3 ... Directory server, 5A, 5B ... Client computer, 11 ... Storage, 31
… User information DB (database).

Claims (5)

[Claims] 1. A document processing apparatus comprising a document management unit for placing a document under a folder and managing the document according to an access right set for the document and the folder, wherein the document management unit is user attribute information. The access right setting information indicating the access right set for the document and the folder in association with the above is held in advance, and the instruction content indicated in the user's access request is checked by the access right setting information.
A document processing apparatus characterized in that an access right is permitted according to a matching setting condition. 2. The document processing apparatus according to claim 1, wherein the document management unit, when the user attribute information is post information of an organization having a hierarchical structure, requests access when granting an access right. A document processing apparatus characterized in that an access right set in association with a post located at a higher level is also permitted to a post as an attribute of a user who has made a request. 3. The document processing apparatus according to claim 1 or 2, wherein the user attribute information in the access right setting information is a combination of a plurality of attribute information. 4. The document processing apparatus according to claim 1, wherein the access right setting information is a combination of user information and user attribute information, and an access right set for a document and a folder. A document processing device characterized by showing the relation of. 5. A computer program for placing a document under a folder and managing the document according to the access right set for the document and the folder, based on a user's access request for the document and the folder under the control. The step of acquiring the user's attribute information and access type information, and the acquired user's attribute information and access right type are associated with the user attribute information prepared in advance to indicate the access right set for the document and folder. A computer program for executing each processing step of checking by the access right setting information and permitting an access right matching the check result.