[Description of the Symbols]

[0045] 10 : Policy evaluation module

[0046] 20 : Enforcement function verification module

[0047] 30 : Enforcement module

[0048] 40 : Resource document

[0049] 100 : Access control system

[0050] 200 : Data management server

[0051] 210 : Data file

[0052] 220 : Data management sub-system

[0053] 230 : User verification sub-system

[0054] 240 : Access control sub-system

BEST MODE FOR CARRYING OUT THE INVENTION

[0055] The preferred embodiment of the present invention will now be described in detail while referring to the accompanying drawings.

[0056] As an overview of the present invention, the results of a policy evaluation performed in the access control are represented not by a conventional binary decision of Yes or No, but by a multi-valued decision using Boolean algebra, and an intermediate value is interpreted as, “Yes, if this condition is established.” Thus, a frame is provided that can generally represent the policy evaluation process and the enforcement of a condition to carry out the policy. For this, the policy description for access control is extended into the If-then rule, and the partial evaluation method is employed to evaluate a logical language. The If portion is used for checking the condition and for an actual instruction. Therefore, the policy description can be simplified and rendered declarative, and the matching of the overall policy can be determined within the frame of the logical language.

[0057] FIG. 1 is a diagram for explaining the arrangement of a data management server on which an access control system according to this embodiment is mounted. In FIG. 1, a data management server 200 comprises: a data file 210 , in which data and documents to be accessed are stored; a data management sub-system 220 , for managing data and documents and for providing services, such as search; a user verification sub-system 230 , for permitting only registered users to employ the function of the data management server 200 ; and an access control sub-system 240 , for, in conjunction with the user verification sub-system 230 , receiving only specific access requests from registered users and for exercising access control to ensure that the users receive services available from the data management sub-system 220 . The data management server 200 receives from an external source the data and the documents that are to be managed, and various user associated data that are employed for the access control provided by the access control sub-system 240 . In FIG. 1 , the chart of the organization to which a user belongs is requested in order to acquire the user's ID from a predetermined external file 300 , and time information is obtained from a time stamp server 400 .

[0058] A user who desires to access data, or a document stored in the data management server 200 , first accesses the user verification sub-system 230 of the data management server 200 from a user terminal 500 and logs in to the system. At this time, the user verification sub-system 230 examines a password, for example, to determine whether it was submitted by a registered user (an entity permitted to access data or documents managed by the server).

[0059] Then, the user issues an access request for desired data to the access control sub-system 240 . The access control sub-system 240 employs log-in information received from the user verification sub-system 230 , the contents of the access request, and the provisions of the security policy for access control to determine whether or not permission should be granted. At this time, as needed, the organization chart and the time information are input for the access permission determination.

[0060] When access permission is granted by the access control sub-system 240 , pertinent data or a document is read from the data file 210 by the data management sub-system 220 and is transmitted, via the access control sub-system 240 , to a user terminal 500 . While a detailed description of the operation will be given later, here it should be noted that the access control sub-system 240 can convert the obtained data, or in accordance with the contents of the policy description, can add history information (a log file, etc.) to the original data.

[0061] FIG. 2 is a diagram for explaining the overall arrangement of the access control system according to the embodiment. An access control system 100 in FIG. 2 corresponds to the access control sub-system 240 in FIG. 1 . In FIG. 2, a policy description evaluation module 10 receives an access request, and evaluates a policy description that is associated with the data that are to be accessed. When a condition (hereinafter referred to as an external condition) included in the policy description that is to be evaluated can not be evaluated using only the information included in the policy evaluation module 10 , an enforcement function verification module 20 determines whether the evaluation or the establishment of the external condition is possible. Then, if the enforcement function verification module 20 determines evaluation or establishment is possible, the evaluation or the establishment of the external condition is performed by an enforcement module 30 , a plurality of which can be provided in accordance with the results obtained by the evaluation or the establishment of the external condition. When multiple enforcement modules 30 are provided, the enforcement function verification module 20 performs an examination to determine whether any of the enforcement modules 30 can evaluate or establish the external condition received from the policy description module 10 . The final component is a resource document 40 that stores a policy description associated with the data that are to be accessed. In the access control system 100 , which is implemented by a computer, the above described individual modules, which in operation are comparable to program modules, are used to perform functions that permit the computer to perform the individual processes.

[0062] FIG. 3 is a table for defining the contents of data that are input to and output by the modules 10 , 20 and 30 . While referring to FIG. 3 , the structure of an access request 110 or 130 that is input to the policy evaluation module 10 is (Subject, Object, Role (or Uid), Operation). The structure of external condition information signal 113 , which is transmitted by the policy evaluation module 10 to the enforcement function verification module 20 , is a condition list {Condition-List}. The structure of an enforcement instruction 121 , which is transmitted by the enforcement function verification module 20 to the enforcement module 30 , is a data set {Instruction-Set} instructing the enforcement of an operation. A policy description 140 , which is read from the resource document 40 by the policy evaluation module 10 , a document 134 , which is transmitted by the data file 210 in FIG. 1 , via the data management sub-system 220 , to the enforcement module 30 , and update information 133 , which is transmitted by the enforcement module 30 , via the data management sub-system 220 , to the data file 210 , are XML documents. Access inhibited data strings 112 , 120 and 131 , which are respectively output by the policy evaluation module 10 , the enforcement function verification module 20 and the enforcement module 30 , are data strings (“denied” strings) that are transmitted when access is denied. An access permitted data string 111 , which is output by the policy evaluation module 10 , is a data string (a “permission” string) that is transmitted when access is permitted. And a resource transcode document 132 , which is output by the enforcement module 30 , is a document such as an HTML or XML document, or a data string (an HTML or XML string, etc.).

[0063] FIG. 4 is a flowchart for explaining the processing performed by the access control system 100 in FIG. 2 when handling an access request.

[0064] The processing sequence in FIG. 4 is initiated upon the receipt of an access request 110 from a user, or is recurrently begun upon the receipt of an access request 130 that is secondarily issued by a specific enforcement module 30 during the processing performed to handle the access request.

[0065] Upon receiving the access request 110 or 130 , the policy evaluation module 10 detects, from the resource document 40 , a policy description 140 that corresponds to the document that is to be accessed (step 401 ), and performs an evaluation of the extracted policy description 140 (step 402 ). When all the conditions in the policy description 140 are permissible, in accordance with the evaluation results, either an access permitted data string 111 or an access inhibited data string 112 is returned to the user who issued the access request (steps 403 , 404 and 405 ).

[0066] When a condition included in the policy description 140 is one for which the policy evaluation module 10 can not provide a final evaluation, it is ascertained that conditional permission is applicable, and the external condition information 113 is transmitted by the policy evaluation module 10 to the enforcement function verification module 20 (step 403 ).

[0067] Available at the enforcement function verification module 20 is a list of the various enforcement modules 30 that are provided for the system. Thus, upon the receipt of the external condition information 113 , the enforcement function verification module 20 searches for an enforcement module 30 that can evaluate or establish the external condition (step 406 ). When no appropriate enforcement module 30 is found, an access inhibited data string 120 is returned to the user who issued the access request 110 (steps 407 and 48 ).

[0068] When an appropriate enforcement module 30 is found that can evaluate or establish the external condition, the pertinent enforcement module 30 is called and the evaluation or the establishment of the external condition is performed (steps 407 and 409 ). When, as a result of an evaluation, the enforcement module 30 determines that access permission for the external condition is appropriate, or if the enforcement module 30 can successfully establish the external condition, the resource transcode document 132 is transmitted, and the policy evaluation module 10 proceeds with the evaluation of another condition in the policy description 140 (step 410 ). When all the conditions in the policy description 140 have been evaluated and access permission has been verified, an access permitted data string 111 , together with the resource transcode 132 extracted by the enforcement module 30 , is transmitted to the user who issued the access request 110 .

[0069] However, when, as a result of an evaluation, the enforcement module 30 determines that access permission for the external condition should be inhibited, or if the enforcement module 30 fails to establish the external condition, an access inhibited data string 131 is transmitted to the user who issued the access request 110 (step 411 ).

[0070] In the processing performed by the enforcement module 30 , when access to another document, or to another section in a document to be accessed, is required in order to establish an external condition, an access request 130 can be issued to the policy evaluation module 10 to repeat the evaluation of the external condition. When the repeated access request that is issued to establish the external condition is defined as an evaluation target for access permission, an evaluation at another level can be performed, and the security can be improved.

[0071] Further, when in order to establish an external condition the enforcement module 30 requires personal information, such as the structure of an organization a user belongs to or an access date, the required information can be obtained by accessing a file or a server that can provide this information.

[0072] The functions of the individual modules will now be described in detail.

[0073] FIG. 5 is a flowchart showing a policy evaluation algorithm used by the policy evaluation module 10 . FIGS. 6 and 7 are diagrams for explaining an example format and an example expression used for data that are input to or output by the policy evaluation module 10 .

[0074] In FIG. 5 , an access request 110 is input and parameters are accepted (step 501 ). By referring to the column occupied by an access request in FIG. 6 , the format can be determined for an access request 110 that employs, as parameters, Subject, which is data used to identify the subject (a user, etc.) by which the access request was submitted; Object, which is data used to identify an access target; and Operation, which is data used to identify an operation to be performed for the access target. These parameters convey the meaning, “Subject requests use of Object to perform an Operation (access right).” A specific access request example is shown in FIG. 6 . In this example an access request is submitted wherein the Subject submitting the access request is Nihon Taroh/IBM/Japan, the Object is http://admin.trl.com//form//expense.xml, and the Operation is read(html). The meaning conveyed by this access request is, “A user who logged in as ″Nihon Taroh/IBM/Japan requests permission to read, in HTML form, the file expense.xml stored in the admin.trl.com server.” For this processing, the access request 110 is input, and the same activities are performed as are performed when an access request 130 output by the enforcement module 30 is received.

[0075] Then, a rule that matches all the parameters (Subject, Object and Operation) in the access request is searched for in the access control policy description that is stored in the resource document 40 (step 502 ). The detected policy rule 140 is input, and by referring to the column for the access control policy rule in FIG. 6 it can be determined that for the policy rule format, employed as parameters are Subject, which is data used to identify a user for which access is permitted; Object, which is data used to identify a target for which access is permitted; Operation, which is data to identify an access permission operation; and Condition, which is a description of a condition under which access permission is granted. Together these parameters constitute the rule, “When the description in Condition is established, Subject possesses the right to perform an Operation using Object.” A specific example for the policy rule is shown in FIG. 6 , wherein Subject is an employee, Object is http://admin.trl.com//expense.xml, Operation is read(html), and Condition is transcode (in, out). The meaning conveyed by the policy rule is, “So long as data can be converted into HTML, a user or an application filling the role of “employee” (has right to access data) is permitted to read file expense.xml stored in the admin.trl.com server.”

[0076] Here, “matching” means that the values of Subject, Object and Operation are matched. For example, when the Subject in the access evaluation request parameter is “amano,” the rule whereby user ID “amano” and group name TRL, which includes “amano,” are described is extracted from the access control policy rules.

[0077] During the search of the access control policy rule, environment data that are stored in the resource document 40 are also received in order to look for matching parameters. By referring to the column for the environment data in FIG. 7 , the format for environment data employs, as a parameter, Environment, which is a list of facts or an arbitrary fact that in the policy evaluation module is true. This parameter means that “Environment is regarded as true in the policy evaluation.” A specific example for the environment data is shown in FIG. 7 , and in this example, the fact that user Nihon Taroh/IBM/Japan can fill the role of “employee” is included as environment data. It is apparent that when the environment data is applied for the examples for the access request and policy rule in FIG. 6 , user ″Nihon Taroh/IBM/Japan, which is included in the access request, satisfies the condition in the policy rule for the user who can fill the role of “employee” in the policy rule.

[0078] In the rule examination process, when a plurality of policy rules are matched at step 502 a method for evaluating these policy rules is determined (step 503 ). For example, when priorities are assigned for the policy rules, the policy rules are rearranged in the order of their priorities so that a correct evaluation can be made, or a rule for providing a preference for access inhibited rather than access permitted is prepared, and the policy rules are sorted into two types and are thereafter rearranged. Thus, the careless granting of access permitted can be prevented. The process performed when there are no matched rules is also determined at this step. For example, for a closed policy, access inhibited is determined unconditionally.

[0079] The condition portions of the policy rules that are processed at step 503 are then evaluated (step 504 ). When a condition using a value that is present in the resource document 40 is described in a condition portion of the policy rules, the pertinent value is extracted from the resource document 40 . In a condition portion, a condition based on a value extracted from the resource document 40 is regarded as one that must be evaluated.

[0080] The results obtained at step 503 are used for the evaluation of conditions (step 505 ). When all the conditions can be evaluated and all the conditions are evaluated as true, an access permitted determination is made (step 506 ). When all the conditions can be evaluated and one or more conditions are evaluated as false, an access inhibited determination is made (step 508 ).

[0081] When there are conditions that can not be evaluated, an external condition is prepared under the terms of which access permitted determinations can be made for the conditions that could not be evaluated, and program control is shifted to the enforcement function verification module 20 (step 507 ). By referring to the column for the external condition in FIG. 7 , it can be seen that the format for the external condition employs, as a parameter, ExternalCondition, a list, in the policy evaluation module 10 , of assumptions that have neither been proven true nor been proven false. This parameter means “In accordance with Condition of the access control policy rule, a condition that can not immediately be determined to be true or false by using the environment data and the system function of the policy evaluation module.” A specific example of the use of the external condition is shown in FIG. 7 . As a result of an evaluation of the access request and the policy rule in FIG. 6 , the external condition for determining whether expense.xml can be converted into HTML is transmitted from the policy evaluation module 10 to the enforcement function verification module 20 .

[0082] When program control is shifted to the enforcement function verification module 20 , program control is returned, via the enforcement module 30 , to the policy evaluation module 10 , which thereafter determines whether a final evaluation can be made. It should be noted, however, that, as will be described later, when the enforcement function verification module 20 or the enforcement module 30 ascertains that the external condition can not be evaluated or established, program control is not returned to the policy evaluation module 10 and an access inhibited determination is made.

[0083] FIG. 8 is a flowchart for explaining an enforcement function verification algorithm used by the enforcement function verification module 20 , and FIG. 9 is a diagram for explaining the format for data used by the enforcement function verification module 20 .

[0084] While referring to FIG. 8 , first, information for the external condition is received from the policy evaluation module 10 and is used for making an access permitted determination under a condition, and information for Component, which is registered as the enforcement module 30 , is read from the enforcement module list stored in the enforcement function verification module 20 (step 801 ). While referring to FIG. 9 , the format used for the information for the enforcement module 30 that is obtained from the enforcement module list, employs, as parameters, Condition Expression, which is a condition portion of an access request under a condition; Capability, which indicates the presence/absence of a component that can handle the condition; Component Name, which is a designated component that processes the condition; and Component Argument, which is the argument for the component. A specific example of the information as it concerns the enforcement module 30 is shown in FIG. 9 , wherein the information that is presented for Condition Expression is transcode#type#1 (*.xml, html), for Capability Check is Available, for Component Name is c:¥tools¥jar¥enforcerl.jar, and for Component Argument is c:¥enforcement¥transcode#type#l.xsl. What these information entries mean is, “The Enforcement mechanism that establishes the external condition ‘transcode#type#l’ can be employed, and data are processed by providing the ‘transcode#type#l.xsl’ parameter file for the ‘enforcerl.jar’ program, so that the condition can be established.”

[0085] Multiple conditions that are input as external conditions are extracted one by one (step 802 ). A check is performed with each to determine whether an entry that satisfies the condition extracted at step 802 is included in the Condition Expression obtained at step 801 (step 803 ). If such an entry is included, the next condition is compared with Condition Expression. This process is repeated until all the conditions that constitute the external condition have been compared (step 804 ).

[0086] If an entry that satisfies the condition is not included in even one of the conditions that constitute the external condition, the access inhibited data string 120 is output, and the processing is thereafter terminated (step 805 ).

[0087] If an entry that satisfies the condition is detected for all the conditions that constitute the external condition, i.e., if all the parameters for the external condition are examined, program control shifts to the processing performed by the enforcement module 30 . The format of the enforcement instruction 121 issued to the enforcement module 30 consists of a plurality of lists of combinations of Component Name and Component Argument included in the information that is read from the enforcement module list. For example, ((lotusxsl.jar, transcode.xsl) (domhash.jar, signature.xml)).

[0088] FIG. 10 is a diagram for explaining an example arrangement of the enforcement module 30 . While referring to FIG. 10 , the enforcement module 30 includes a writing/change target detection means 31 , an XSL processor 32 , and a filter program 33 that can be plugged in.

[0089] The writing/change target detection means 31 detects a portion in an XML document for which writing or conversion can be performed. The XSL processor 32 is a standard tool for reading XML data and a conversion rule, and for generating new XML data. The filter program 33 executes an instruction for handling the contents that the XSL processor 32 can not process. A desired function can be added by employing a plug-in.

[0090] In the processing handled by the enforcement module 30 , a specific conversion is performed for the XML document in the data file 210 to obtain another XML document. The enforcement instruction 121 , which refers to specific portions of the enforcement processing, is expressed as XSL data used to describe the conversion rule employed for the XML document.

[0091] FIG. 11 is a flowchart for explaining the enforcement processing performed by the enforcement module 30 . In accordance with FIG. 11 , the writing/change target detection means 31 analyzes the conversion rule (enforcement instruction 121 ) that is expressed using XSL, and detects a portion of the target XML document that may be written to or changed (step 1101 ). Since the enforcement process is performed by the enforcement module 30 in order to establish a condition required for the evaluation of the first access request 110 , the XML document to be converted is not always an access target for the access request 110 . For example, the XML document can be an additional file that is associated with the target data file of the access request 110 . The detection of the target to be written or changed is performed by a trial application of the conversion rule to the target document 134 , and by comparing the tree structures of the resulting document 134 and the original document. When the writing of addition data or the changing of original data becomes necessary as a result of the enforcement of an instruction, the access request 130 is issued as an inquiry to the policy evaluation module 10 (step 1102 ). Thereafter, the pertinent processing is continued only if access permission is received from the policy evaluation module 10 (step 1103 ).

[0092] When access is inhibited by the policy evaluation module 10 , the processing that was being performed in accordance with the enforcement instruction is halted and the process is returned to its original state, or the data for which the temporary processing was performed are not written back to the resource document 40 (step 1108 ), and the enforcement function verification module 20 and the policy evaluation module 10 are notified that the attempt to establish the condition failed (step 109 ). The processing is thereafter terminated. In this case, neither the evaluation nor the establishment of the pertinent condition is possible, and for the access request, an access inhibited string 131 is output.

[0093] When access is permitted by the policy evaluation module 10 , the XSL processor 32 performs the conversion of the XML document 134 (step 1104 ). But when a detailed enforcement procedure, such as encoding or watermarking, can not be directly accomplished using XSL, the XSL processor 32 inserts only an encoding or watermarking instruction into the XML document 134 , and the actual processing is subsequently performed by an appropriate filter program 33 (step 1105 ).

[0094] When all the conversions included in the enforcement instruction 121 have been accomplished, the enforcement module 30 notifies the enforcement function verification module 20 and the policy evaluation module 10 of the establishment of the condition (steps 1106 and 1107 ). The processing is thereafter terminated. The XML document data obtained by the XSL processor 32 and the filter program 33 are again stored, via the data management sub-system 220 , as updated information 133 in the data file 210 , or are transmitted, together with the access permission response 111 , as the resource transcode 132 to the transmission source of the access request 110 .

[0095] A specific example application of the embodiment will now be described.

[0096] An explanation will be given for an example wherein the embodiment is employed for the transcoding of data. The transcoding of data is a process during which the format of information written by a single source is converted in accordance with the security level of an access request source and the capabilities of a communication channel and a display device, and the obtained information is transmitted. In this example, a policy is described whereby when a reading request is issued to prepare written information based on XML (names representing the definitions of individual fields are written using XML tags), reading is permitted using an HTML form that is not as re-usable. The policy rule is written, for example, as follows.

[0097] acl(*, role(employee), doc(http://trl.ibm.com/xmlform/X), read(Form))≦transcode (X, xml, Form).

[0098] Assume that an access request is issued to obtain a travel expense application form via HTML. This access request is written as follows.

[0099] ?-acl(amano, role(employee)

[0100] doc(http://trl.ibm.com/xmlform/travelExpenseAccount.xml), read(html)).

[0101] In this case, role(employee) is matched as Subject, both in the policy description and the access request, and Object in the access request is

[0102] doc(http://trl.ibm.com/xmlform/travelExpenseAccount.xml) and is included in Object in the policy description, doc(http://trl.ibm.com/xmlform/X). However, since Condition ‘transcode(X, xml, Form)’ is provided for Operation ‘read(html)’, the evaluation obtained by the policy evaluation module 10 is access permission for which a condition applies. The external condition that the policy evaluation module 10 transmits to the enforcement function verification module 20 is a condition according to which access is permitted if an XML form can be converted into an HTML form. The external condition is described as follows.

[0103] transcode(travelExpenseAccount.xml, xml, html)

[0104] Therefore, if the access control system 100 includes the enforcement module 30 , which can convert a target form written in XML into an HTML form, the access is permitted. When such an enforcement module 30 is prepared, the XSL description is provided for the enforcement module 30 to convert the target form written in XML into the HTML form. The XSL processor 32 processes the XSL description and the original form data to generate HTML data for display. The obtained HTML data are thereafter transmitted to the user who issued the access request.

[0105] An example wherein the above embodiment is employed to insert an electronic watermark into a document will now be described. This process can be a modification of the transcoding process. Specifically, a condition is prepared whereby access is permitted if the ID of a user who has submitted an access request is embedded in an image/X as a policy description. The rule that includes this condition is written as follows.

[0106] acl(user(ID), role(subscriber),

[0107] doc(http://trl.ibm.com/image/X), read)≦embed(X, ID).

[0108] When a detailed enforcement procedure, such as a complicated electronic watermarking process, can not be written directly, the XSL processor 32 inserts, into a target document, only an instruction for the embedding of an electronic watermark. The actual embedding process for the electronic watermark is subsequently performed by a special filter program 33 . The same method can be employed to execute an instruction for providing a condition whereby access is permitted if a data file is encoded.

[0109] An explanation will now be given for an example for which the embodiment is used for the writing of a data operation in a log file. For the access control system it is important that auditability be ensured. For this, it is convenient to provide a configuration that maintains a log (history) for an operation for which specific data are used. In this example, a case wherein a log is required is described as a policy, and this policy is enforced. The policy description is as follows.

[0110] acl(user(ID), role(issuer),

[0111] doc(http://trl.ibm.com/xmlform/X), write(*))≦status(log(ID, issuer, X, write, T)).

[0112] Assume that the following access request is issued for this policy description.

[0113] ?-acl(amano, role(issuer)

[0114] doc(http://trl.ibm.com/xmlform/travelExpenseAccount.xml#linp utfield), write(“cost=$100”)).

[0115] In this case, role(issuer) is matched as Subject both in the policy description and in the access request, and Object in the access request is doc(http://trl.ibm.com/xmlform/travelExpenseAccount.xml#linp utfield) and is included in Object in the policy description, doc(http://trl.ibm.com/xmlform/X). However, since Condition ‘status(log(ID, issuer, X, write, T)’ is provided for Operation “write(“cost=$100”),” it is assumed that the following rules are provided for “status.”

[0116] status(log(Subj, Role, Obj, Op, T))≦log(Subj, Role, Op, T).

[0117] status(log(Subj, Role, Obj, Op, T))≦makelog(Subj, Role, Op, T).

[0118] Since the status data “log” is not yet written, the first rule of “status” fails. The second rule is employed, and access is permitted under a condition makelog(..).

[0119] Upon the receipt of the “makelog” request, the enforcement module 30 analyzes a corresponding enforcement instruction 121 , and detects that writing to the original data is required. To obtain write permission, the enforcement module 30 transmits the access request 130 to the policy evaluation module 10 . The access request 130 is written as follows.

[0120] ?-acl (sys1, role (system)

[0121] doc(http://trl.ibm.com/xmlform/travelExpenseAccount.xml#log) , write(log(amano, issuer,

[0122] travelExpenseAccount.xml#issuerField, write(“cost=$100”))).

[0123] The access permission or inhibition provided in response to the access request 130 is determined by again evaluating the policy rule. When access is permitted, a log is written, and if the condition is established, access is also permitted for the original access request. Therefore, in response to the original access request, the log is stored in a document that is to be accessed.

[0124] The actual process for writing a log is described as a conversion rule between XML documents, as well as in transcoding. For example, the description (written in accordance with instructions for writing the XSL conversion rule) shown in FIG. 12 is prepared and registered in the system in order to maintain a log for the accessing, for example, of information concerning orders for parts. According to this description, information for quantities and for delivery times for parts, represented by “GR Head”, and the person to whom the information is disclosed are recorded. In FIG. 12, a portion “&Subject ” enclosed by an ellipse is a parameter (an access issuer in this case) that is designated when the enforcement process is begun. When the XSL processor 32 processes the description in which the “&Subject” portion is replaced with the actual company name and the description of the order information, a document in FIG. 13 to which the log is added is generated.

[0125] Following this, an explanation will be given for an example wherein the embodiment controls access by applying the constraints imposed by a time condition. When bidding or an auction takes place on the Internet, the granting of access permission in accordance with the condition, “This information may be read after a specific date at a specific time,” must be strictly controlled. An explanation will be given to describe a policy that establishes the time at which access is permitted. This policy is called access permission under a time condition (Temporal Authorization). The policy description for such access permission is conventionally written as follows.

[0126] acl(AnyUserID, role(employee),

[0127] doc(http://announce/bonus.xml), read):-get#time(T), T>“1999/06/03.”

[0128] This means that “a user filling the ‘employee’ role has the ‘read’ right for ‘http://announce/bonus.xml’ after Jun. 3rd, 1999.” In this case, the system term “get#time” obtains the current time, and if the current time is later than Jun. 3rd, 1999, the condition is established and the ‘employee’ can be granted the ‘read’ right for the ‘bonus.xml’.

[0129] When access permission is controlled under this condition, however, the security of the access control system depends on the value held by the system clock of the server. For example, if a system manager should intentionally change the system clock of the server that controls the access, the “employee” would be able to “read” the “bonus.xml” at a time whereat he or she does not have the “read” right. Even when “read” accesses are maintained in a log, if the value held by the system clock is used to determine the access time, an access that is illegal relative to the time-limited access permission control can not be detected. Further, it tends to be assumed that access control at the OS level is performed in accordance with the system clock of the server. However, for granting the above permission, the assumption of the access under the time condition at the OS level is not required.

[0130] In the example, whether or not the above embodiment is used for access permission under a time condition, the policy description for access permission is written as follows.

[0131] acl(user(ID), role(employee),

[0132] doc(http://announce/bonus.xml), read) :- status(timestamp(S, T)), verify#signature(S), T>“1999/06/03.”

[0133] In accordance with the policy description, the access control system 100 performs the following process for each module.

[0134] First, the policy evaluation module 10 evaluates the policy description. Assume that the following rules are written concerning “status(timestamp(S, T)).”

[0135] status(timestamp(S, T)) :- timestamp(S, T).

[0136] status(timestamp(S, T)) :-get#timestamp(S, T), makelog(timestamp(S, T)).

[0137] Since the time stamp data “timestamp(S, T)” have not yet been written to the resource document 40 , the first rule of the “status” fails. The second rule is employed, and the access is permitted under conditions “get#timestamp(S, T)” and “makelog(timestamp(S, T)). Since verify#signature(S) and T >“1999/06/03” can not be evaluated by the policy evaluation module 10 , access is also permitted under the condition. Finally, get#timestamp(S, T), makelog(timestamp(S, T)), verify#signature(S) and T>“1999/06/03” are defined as the external conditions 113 , which are then transmitted by the policy evaluation module 10 to the enforcement function verification module 20 .

[0138] The enforcement function verification module 20 examines the enforcement modules 30 to determine whether there is one that can evaluate or establish the external conditions. In this case, a table for the enforcement function verification module 20 is as shown in FIG. 14 . The table in FIG. 14 shows the presence/absence of an enforcement module 30 that can process the contents represented by the Condition Expression, and the Component name of the enforcement module 30 that can process the contents. In the table in FIG. 14 , makelog/ 1 means the “makelog” term of argument 1 , and “formula#expression” means a formula expression including four rules of arithmetics. It is apparent from the table that all the condition portions for granting access permission under the condition can be processed by the enforcement module 30 . Thus, [timestamp#processor, get#timestamp(S, T)], [log#processor, makelog(timestamp(S, T)], [signature#processor, verify#signature(S)], and [formula#processor, T>“1999/06/03”] are transmitted as enforcement instructions 121 by the enforcement function verification module 20 to the enforcement module 30 .

[0139] The enforcement module 30 performs the processing in accordance with each of the enforcement instructions 121 . Each process will now be described.

[0140] Process for get#timestamp(S, T)

[0141] The time stamp processor performs the process for get#timestamp. The following enforcement program is written to the time stamp processor.

[0142] get#timestamp(S, T) :- get#trust(timestamp, C), get#timestamp(C, T, S).

[0143] get#trust/2 is a term for extracting the “trust” description from the data file 210 . Assume that the following “trust” description is included in the original document.

[0144] trust(timestamp, “http://www.surety.com”).

[0145] This means that for the document “surety” is trusted as the “timestamp.” As a result of the search of the document 141 from the data file 210 , “http://www.surety.com” is allocated for the variable C in “get#trust.” Then, in accordance with the “get#timestamp” term, the time stamp S for the time T is obtained from the Surety Timestamp Service. As a result, the first condition of the enforcement instructions 121 is established. In this embodiment, Timestamp Service is not limited to Surety, and any service for the original document that can be trusted can be written in.

[0146] Process for makelog(timestamp(S, T))

[0147] For “makelog” the process is performed by the log processor. The log processor issues the access request 130 to write the following log.

[0148] acl(sysl, role(system), doc(http://announce/bonus.xml#log), write)

[0149] Whether the log can be written is determined by again evaluating the policy description. When the access control system 100 has the right to write a log, access of the enforcement module 30 is permitted by the policy evaluation module 10 . Thus, “makelog” writes the time stamp “log(timestamp(signature#value, 1999/06/04)).

[0150] Process for verify#signature(S)

[0151] The process for “verify#signature” is performed by a signature processor. The signature value of the time stamp is examined, and if it is Valid, “true” (correct signature) is returned, while if it is Invalid, “false” (incorrect signature) is returned. It should be noted that the signature value of Surety is Valid.

[0152] Process for T>“1999/06/03”

[0153] The formula expression is performed by the form processor. T is the value of the time held by the time stamp, i.e., 1999/06/04. Since T>“1999/06/03” is established, “true” (correct form) is returned.

[0154] Through the above processing, the enforcement instructions 121 , get#timestamp(S, T), makelog(timestamp(S, T)), verify#signature(S() and T>“1999/06/03,” that are transmitted by the enforcement function verification module 20 to the enforcement module 30 are all true. Thus, all the conditions acl(user(ID), role(employee),

[0155] doc(http://announce/bonus.xml), read), which are requested by the policy evaluation module 10 , are established.

[0156] An explanation will now be given for the resolving, under a time condition, of an access permission problem that was first described. When in the above example access is permitted, the value of the time stamp is always added to the log area of the original document. The value of the time stamp indicates that the data was generated at a predetermined time, and the presence of the time stamp value in the log area indicates that the current time is always later than the time stamp time. Therefore, if the system manager changes the system clock value of the policy evaluation module 10 or the enforcement module 30 , a correct examination of the time condition can be performed by referring to the time stamp value.

[0157] As is described above, according to the access control provided by the present invention, upon the receipt of an access request, not only can whether or not an access should be permitted be determined, but also access permission under a condition whereby an access is permitted if a specific condition is established can also be evaluated. Further, when it is requested that a condition that is to be evaluated for access permission under a condition establish a different condition, the different condition can also be currently evaluated.

[0158] The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has embodied therein, for instance, computer readable program code means for providing and facilitating the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

[0159] Additionally, at least one program storage device readable by a machine, tangibly embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

[0160] The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

[0161] Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.