Access control program, access control method and access control device

Abstract

To provide a technology capable of restricting access in a situation unintended by a user in capability / role-based access control.SOLUTION: In an access control device 10, a capability monitoring unit 20 acquires an identifier of capability and a request from a user, and acquires context information of the user. A context management unit 22 compares a context rule associated with the identifier of the capability with the context information. When the context information satisfies the context rule, a capability management unit 24 executes processing according to the request if constraints on the use of the capability are satisfied.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a technique for controlling access to resources. [Background technology]

[0002] In role-based access control (RBAC), in a system used within the same organization, roles, i.e., the roles of the users, are used when granting access rights to users. Patent Document 1 discloses a technology that enables granting access rights according to the location of a user in role-based access control by rewriting the role based on the location information of the user's mobile terminal. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-55297 Summary of the Invention [Problem to be solved by the invention]

[0004] Capability-Role-Based Access Control (CRBAC) is a technology that extends role-based access control with capability-based access control. With this technology, it is possible to easily transfer access rights to members of different organizations by using capabilities. In addition, users with capabilities can create more restricted access rights based on those capabilities without administrator intervention, which allows for decentralized management of access rights. However, this technology cannot handle context information such as the user's location, time, or device, making it difficult to restrict access in unintended situations.

[0005] The object of the present invention is to provide a technology that can restrict access in unintended circumstances in capability-role-based access control. [Means for solving the problem]

[0006] In order to solve the above problem, an access control program of one embodiment of the present invention causes a computer to perform the following steps: obtaining a capability identifier and a request from a user; obtaining context information of the user, the context information including the user's current location; comparing the context information with a context rule associated with the capability identifier; and, if the context information satisfies the context rule, performing processing in accordance with the request if constraints on the use of the capability are satisfied. The request is a use request to access a resource using a capability or a management request for a capability. The management request is a create request to create a new capability, a transfer request to send a capability identifier to another user, an update request to update a capability, or a disable request to disable a capability. A capability is associated with a base role, and when a capability is created from a base role in response to a create request, it is possible to specify whether the capability is directly associated with the base role or whether the capability is associated with the base role via a metacapability. When a capability is directly associated with a base role, the capability is disabled in response to a disable request by a user who holds the base role. When a capability is associated with a base role via a metacapability, the capability is disabled only in response to a disable request by a user who holds the metacapability.

[0007] Another aspect of the present invention is a computer-implemented access control method, the method comprising the steps of: obtaining a capability identifier and a request from a user; obtaining context information of the user, the context information including a current location of the user; comparing the context information with a context rule associated with the capability identifier; and, if the context information satisfies the context rule, performing processing in accordance with the request if constraints on use of the capability are satisfied. The request is a use request to access a resource using a capability or a management request for a capability. The management request is a create request to create a new capability, a transfer request to send a capability identifier to another user, an update request to update a capability, or a disable request to disable a capability. A capability is associated with a base role, and when a capability is created from a base role in response to a create request, it is possible to specify whether the capability is directly associated with the base role or whether the capability is associated with the base role via a metacapability. When a capability is directly associated with a base role, the capability is disabled in response to a disable request by a user who holds the base role. When a capability is associated with a base role via a metacapability, the capability is disabled only in response to a disable request by a user who holds the metacapability.

[0008] Yet another aspect of the present invention is an access control device, comprising: a capability monitoring unit that receives a capability identifier and a request from a user and receives context information of the user, the context information including a current location of the user; a context management unit that compares the context information with a context rule associated with the capability identifier; and a capability management unit that executes processing in response to the request if the context information satisfies the context rule and if a constraint on the use of the capability is satisfied. The request is a use request to access a resource using a capability or a management request for a capability. The management request is a create request to create a new capability, a transfer request to send a capability identifier to another user, an update request to update a capability, or a disable request to disable a capability. A capability is associated with a base role, and when a capability is created from a base role in response to a create request, it is possible to specify whether the capability is directly associated with the base role or whether the capability is associated with the base role via a metacapability. When a capability is directly associated with a base role, the capability is disabled in response to a disable request by a user who holds the base role. When a capability is associated with a base role via a metacapability, the capability is disabled only in response to a disable request by a user who holds the metacapability. [Effects of the Invention]

[0009] According to the present invention, capability-role-based access control can restrict access in unintended circumstances. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a diagram illustrating a configuration of an information processing system according to an embodiment. [Figure 2] FIG. 2 is a diagram illustrating a first pattern of a hierarchical structure of capabilities according to an embodiment. [Figure 3] FIG. 10 is a diagram illustrating a second pattern of the hierarchical structure of capabilities according to the embodiment. [Figure 4] 2 is a sequence diagram showing a protocol used in the information processing system of FIG. 1. [Figure 5] 1. FIG. 4 is a sequence diagram showing the processing of a management request using roles in the information processing system of FIG. [Figure 6] 1. FIG. 4 is a sequence diagram showing the processing of a management request using a capability in the information processing system of FIG. [Figure 7] 5 or 6, is a sequence diagram showing the processing when the management request is "create," "transfer," or "update." [Figure 8] FIG. 8 is a sequence diagram showing the processing of a management request following FIG. 5, FIG. 6 or FIG. 7. DETAILED DESCRIPTION OF THE INVENTION

[0011] Before describing the embodiments in detail, the findings underlying this disclosure will be explained. To collaborate across organizations while maintaining organizational structure, members need to share necessary data according to the phase of a project, as well as resources such as servers, computers, and storage, with all related members, whether external or internal. In addition, these days, members have the flexibility to choose where and when they work. In such a flexible and dynamically changing environment, it is important to have an access control mechanism that enables cross-domain access authority delegation across organizations, decentralization of management operations, and context-based access authority assignment to limit access in unintended circumstances.

[0012] (1) Cross-domain access authority delegation Since members of different organizations make up a team, it is necessary to grant access privileges across organizations. Normally, it is necessary to create temporary users within the same organization, i.e., in the same domain, but this can make management cumbersome.

[0013] (2) Distributed management of access rights If access permission settings are controlled by a central administrator, responding to administrator requests can become a bottleneck, potentially resulting in lead times of several days.

[0014] (3) Access control in unintended circumstances, i.e., unintended locations, times, devices, etc. Sensitive information such as personal information is at risk of being stolen and socially hacked when accessed in public places such as cafes.

[0015] With normal role-based access control, it is difficult to satisfy the above (1) and (2). With capability-role-based access control, although it can satisfy the above (1) and (2), it cannot satisfy the above (3) because it cannot handle context information.

[0016] Therefore, in the embodiment, in capability role-based access control, if the user's context information satisfies the context rule associated with the capability identifier, and the constraints on the use of the capability are satisfied, processing according to the request is executed. This makes it possible to handle context information in capability role-based access control, and realizes the above (1) to (3).

[0017] 1 shows a configuration of an information processing system 1 according to an embodiment. The information processing system 1 includes an access control device 10, a first user terminal 12, and a second user terminal .

[0018] The first user terminal 12 is used by a first user who accesses using a capability. As will be described in detail later, a capability is a token that includes an identifier of a target resource and permissions granted to the resource. A capability can also be considered a self-authentication authority for executing operations that are permitted to the target resource. A capability identifier is distributed to pre-designated users who are permitted to use the capability. A single capability identifier may be held by multiple pre-designated users. A single user may hold multiple capability identifiers.

[0019] The second user terminal 14 is used by a second user who accesses it using a role. The role may be, for example, an administrator, a developer, a viewer, etc. A role includes a set of access rights, that is, permissions.

[0020] The first user and the second user may be the same user. Hereinafter, the first user and the second user may be simply referred to as users. The first user terminal 12 and the second user terminal 14 may be a single user terminal.

[0021] The access control device 10 includes a capability monitor 20, a context manager 22, a capability manager 24, a policy manager 26, a context rule storage unit 28, a capability data storage unit 30, a policy storage unit 32, and a role-based access control unit 34. The access control device 10 can be configured as, for example, a server.

[0022] The configuration of the access control device 10 can be realized in hardware terms by the CPU, memory, and other LSIs of any computer, and in software terms by programs loaded into memory, but here we depict functional blocks realized by the cooperation of these. Therefore, it will be understood by those skilled in the art that these functional blocks can be realized in various ways, using only hardware, only software, or a combination of both.

[0023] When a user accesses the first user terminal 12 using a capability, the capability monitoring unit 20 obtains the user's current context information (user_context) and sends the user's context information and the capability identifier (cap_id) to the context management unit 22.

[0024] The user's current context information includes information that describes the user's current situation, i.e., information about the user's surrounding environment, such as the user's current location, the current time, an identifier of the device the user is currently using, etc. The current location may include, for example, the IP address of the first user terminal 12.

[0025] The context manager 22 manages a context rule storage unit 28 that stores, as a database, context rules associated with capability identifiers. Context rules include conditions for allowing access, such as location, time, and device, and are created by the user. The location condition may include, for example, an IP address.

[0026] Based on an instruction received from the capability monitoring unit 20, the context management unit 22 compares the context information with the context rule associated with the capability identifier, and returns the comparison result to the capability monitoring unit 20.

[0027] If the comparison result by the context management unit 22 indicates that the context rule is satisfied, the capability monitoring unit 20 transmits the request sent by the user, the capability identifier, and the options to the capability management unit 24.

[0028] The capability management unit 24 checks the constraints on the use of the capability corresponding to the received capability identifier, and if the constraints are met, executes processing according to the request. In the case of a usage request for accessing a resource, the capability management unit 24 transmits access rights (access token) to the resource to the capability monitoring unit 20, and the capability monitoring unit 20 sends the acquired access rights to the first user terminal 12. In the case of a management request for creating a capability, etc., the capability management unit 24 requests the policy management unit 26 to confirm the operation content of the management request.

[0029] The policy management unit 26 creates policies with restrictions such as the authority that can be assigned to capabilities, the restricted range of constraints and context rules, and the domain that can be specified as a distribution destination. A policy can be created by a user using capabilities. A policy can also be created using, for example, an administrator's role. The policy management unit 26 manages the policy storage unit 32, which stores the created policies as a database by linking them to the creator's role identifier (role_id) or the capability identifier.

[0030] When creating a capability, the policy management unit 26 checks whether the rights, restrictions, context rules, distribution destinations, etc. assigned to the capability satisfy the policy, and returns the check result to the capability management unit 24. The policy applies only to roles or capabilities that are subordinate to the role or capability used when the policy was set.

[0031] If the confirmation result by the policy management unit 26 indicates that the policy is satisfied, the capability management unit 24 executes the management request sent from the capability monitoring unit 20 and operates the capability. If the operation requires a change to the context rule, the capability management unit 24 requests the context management unit 22 to operate the context rule. The capability management unit 24 manages the capability data storage unit 30, which holds capability data and the hierarchical structure of the capabilities as a database.

[0032] The role-based access control unit 34 executes known role-based access control, activating and making available a role assigned to the second user who has logged in through the second user terminal 14. As will be described later, the second user can use the role to create capabilities, etc. The role-based access control unit 34 may also execute known context-based role-based access control (Context-aware RBAC). In context-based role-based access control, the granting of access privileges in the role-based access control is further controlled based on user context information.

[0033] The format of a capability is explained below: A capability includes a capability identifier, a capability body (capability_body), constraints (constraints), a context rule identifier (context_id), and receiving users (receiving_users).

[0034] The capability body contains the identifier of the target resource and a list of identifiers of permissions for that resource. Permissions are also called access rights.

[0035] The restrictions are restrictions on the use of the capabilities, and include, for example, the expiration date of the capabilities, the number of times the capabilities can be used, the number of times permissions can be created, the number of times the capabilities can be transferred, etc. The restrictions are also called constraints.

[0036] The recipient user includes a list of destination email addresses. Note that only the capability identifier is distributed to the user.

[0037] Capabilities are created from roles or capabilities. A hierarchical structure of multiple capabilities is generated with each base role as the root. Information about the hierarchical structure of multiple capabilities is also stored in the database of the capability data storage unit 30.

[0038] The characteristics of the hierarchical structure are as follows: By specifying the identifier of a capability, you can identify all capabilities (hereafter also referred to as children) in the hierarchy below that capability. Note that capabilities in the hierarchy above a capability are also referred to as parents.

[0039] A child only has the same permissions as its parent, i.e., it has permissions for each resource within the scope of its parent's permissions.

[0040] Constraints of a parent are inherited by its children. A child's constraints can be stronger than its parent's. That is, a child can be more restrictive than its parent. For example, if a parent has a usage period constraint, the child can have a usage period constraint with the same or a shorter usage period.

[0041] Only items in the parent's context rule are inherited by the child. For example, if the parent's context rule includes a device specification, the child's context rule also includes a device specification. The values ​​of the items in the child's context rule are set when the capability is created.

[0042] 2 shows a first pattern of the capability hierarchy of the embodiment. In the first pattern, a first capability 61 is created from a base role 50 and is directly connected to the base role 50. In this case, any user who holds the base role 50 can disable the first capability 61 and all of its children, the second capability 62, the third capability 63, and the fourth capability 64. A user who does not hold the base role 50 cannot disable the first capability 61 or any of its children.

[0043] 3 shows a second pattern of the capability hierarchical structure of the embodiment. In the second pattern, the capability management unit 24 automatically creates a meta capability 60 when creating a first capability 61 from a base role 50, and the first capability 61 is indirectly connected to the base role 50 via the meta capability 60. The user who created the first capability 61 owns the meta capability 60. In this case, only the user who owns the meta capability 60 can disable the first capability 61 and all of its children. The meta capability 60 is, for example, a copy of the base role 50.

[0044] The requests to operate and manage capabilities are "use," "create," "delegate," "update," and "revoke." The four requests other than "use" are collectively defined as administrative operations or management requests.

[0045] A use request (req_use) is used when accessing a resource using a capability.

[0046] A create request (req_create) is used to create a new capability using a role or capability.

[0047] A delegation request (req_delegate) is used to transfer existing capabilities to a specific user using a role or capability.

[0048] An update request (req_update) is used to update the capabilities of a target using a role or capability. Update requests can be either a full update (update_full) or a condition update (update_conditions).

[0049] A body update is used to change the capability identifier to a new identifier and change the conditions of the specified capability body, constraints, and context rules. Condition changes are only allowed to strengthen the privileges. Examples of changes that strengthen the privileges include adding new target resources and permissions, adding permissions to existing target resources, and relaxing conditions. A capability cannot be stronger than a higher-level capability. These conditions do not need to be changed. A body update can be used to revoke the privileges of the current holder of the capability while maintaining the capabilities below it.

[0050] Condition updates are used to change the conditions of a specified capability body, constraint, or context rule. As with body updates, condition changes can only increase privileges, and cannot increase privileges beyond those of higher-level capabilities. Condition updates can, for example, extend the expiration date of a capability. Condition updates maintain the capability identifier, so they do not invalidate the privileges of current holders of the capability.

[0051] It is possible to change the conditions that weaken privileges, but in that case, it is necessary to recursively check all lower-level capabilities. By not changing the conditions that weaken privileges, the process can be simplified.

[0052] The req_revoke request is used to revoke a target capability using a role or capability, in which case all children of the target capability may also be revoked.

[0053] Next, we will explain the options sent together with the request. The create request options include a capability body, a context rule (context_rule), constraints, and recipient users. The capability body includes the identifier of the target resource and a list of identifiers of permissions for that resource. The context rule is the context rule you want to set for the capability. The constraints are the restrictions you want to set for the capability. The recipient users include a list of email addresses of users to whom you want to distribute the capability.

[0054] The options for a delegation request include the target capability identifier (target_cap_id) and the receiving users to add (add_receiving_users). The target capability identifier is the identifier of the capability that is the target of the delegation. The receiving users to add contains a list of email addresses of users to whom you want to distribute the target capability.

[0055] The options for an update request include the target capability identifier, additional capability body (add_capability_body), new context rule (new_context_rule), new constraints (new_constraints), and receiving user. The target capability identifier is the identifier of the capability that is the target of the update. The additional capability body includes the identifier of the target resource and a list of permission identifiers for that resource. The new context rule is the new context rule you want to update. If no new context rule is specified, the current context rule will be maintained. The new constraints are the new restrictions you want to update. If no new constraints are specified, the current constraints will be maintained. The receiving user includes a list of email addresses of users to whom you want to distribute the capability.

[0056] The invalidation request options include a target capability identifier, which is the identifier of the capability that is the target of the invalidation.

[0057] Fig. 4 is a sequence diagram showing a protocol used in the information processing system 1 of Fig. 1. Fig. 4 shows, as an example, a process for the first user terminal 12 to access the server 40 (not shown in Fig. 1) which is a resource.

[0058] The first user terminal 12 of the first user transmits a usage request, an identifier of the capability that the first user wishes to use, and a one-time password to the capability monitoring unit 20 (S10). The transmitted capability identifier is a capability that includes the identifier of the server 40 that the user wishes to access.

[0059] The capability monitoring unit 20 acquires the transmitted usage request, capability identifier, and one-time password, verifies the acquired one-time password, and if the one-time password is correct, acquires the user's current context information (S12).The capability monitoring unit 20 transmits the capability identifier and context information to the context management unit 22 (S14).

[0060] The context management unit 22 compares the context information with the context rule associated with the capability identifier (S16) and returns the comparison result to the capability monitoring unit 20 (S18). If the context information satisfies the context rule, the comparison result is "OK", and if the context information does not satisfy the context rule, the comparison result is "NG".

[0061] If the comparison result is "NG," the capability monitoring unit 20 returns information indicating denial to the first user terminal 12 (S20). In this case, the process ends, and the first user terminal 12 cannot access the server 40. This makes it possible to restrict access to resources by users with context information that does not satisfy the context rules. Therefore, it is possible to restrict access to resources in situations unintended by the user.

[0062] If the comparison result is "OK", the capability monitor 20 transmits the usage request and the capability identifier to the capability manager 24 (S22).

[0063] The capability management unit 24 starts the usage procedure based on the received usage request. The capability management unit 24 checks the constraints corresponding to the capability identifier (S24), and if the constraints are met, returns an access token, which is permission to use the access authority, to the capability monitoring unit 20 (S26). If the constraints are not met, the capability management unit 24 returns "NG" as the confirmation result (S26). For example, it is determined that the constraints are not met when the expiration date of the capability has passed.

[0064] The capability monitoring unit 20 returns the result received from the capability management unit 24 to the first user terminal 12 (S28).

[0065] If the received result includes an access token, the first user terminal 12 uses the access token to access the server 40, which is the specified resource (S30). At this time, the capability monitoring unit 20 operates as a proxy.

[0066] If the received result is information indicating denial, the first user terminal 12 cannot access the server 40. This makes it possible to restrict access using capabilities that have expired or exceeded the number of times they can be used. This makes it possible to prevent unintended propagation of capabilities.

[0067] Next, the management operation protocol will be described. (1) Management requests using roles FIG. 5 is a sequence diagram showing the processing of a management request using roles in the information processing system 1 of FIG.

[0068] The second user logs in to the role-based access control unit 34 from the second user terminal 14 (S40), and the role-based access control unit 34 activates the role held by the user according to a known process (S42) and activates the session (S44). At this time, as described above, the role-based access control unit 34 may execute role-based access control based on the context.

[0069] The second user terminal 14 transmits the management request (request (=req_xxx)) and options designated by the user to the role-based access control unit 34 through the activated session (S46).

[0070] The role-based access control unit 34 checks whether the second user has the authority to make the received management request (S48), and if so, sends the management request and options to the capability management unit 24 (S52). Next, if the management request is "create," "transfer," or "update," the process proceeds to S80 in Fig. 7, which will be described later, and if the management request is "invalidate," the process proceeds to S90 in Fig. 8, which will be described later.

[0071] On the other hand, if the user does not have the authority, the role-based access control unit 34 returns information indicating denial to the second user terminal 14 (S50). In this case, the process ends and the management request is not accepted. This makes it possible to restrict the management of capabilities by users with roles for which the user does not have the authority.

[0072] (2) Management requests using capabilities FIG. 6 is a sequence diagram showing the processing of a management request using capabilities in the information processing system 1 of FIG.

[0073] The first user terminal 12 transmits the management request designated by the user, the identifier of the capability to be used, the one-time password, and options to the capability monitoring unit 20 (S60).

[0074] The capability monitor 20 checks the received one-time password, and if it is correct, acquires the user's current context information (S62).The capability monitor 20 sends the capability identifier and the context information to the context manager 22 (S64).

[0075] The context management unit 22 compares the context information with the context rule associated with the capability identifier (S66), and returns the comparison result to the capability monitoring unit 20 (S68).

[0076] If the comparison result is "NG," that is, if the context information does not satisfy the context rules, the capability monitoring unit 20 returns information indicating denial to the first user terminal 12 (S70). In this case, the processing ends and the management request is not accepted. This makes it possible to restrict the user from managing capabilities for context information that does not satisfy the context rules. Therefore, it is possible to restrict the user from performing capability management operations in situations unintended by the user.

[0077] If the comparison result is "OK", that is, if the context information satisfies the context rule, the capability monitor 20 transmits the management request, the capability identifier, and the option to the capability manager 24 (S72).

[0078] The capability management unit 24 checks the constraints corresponding to the capability identifier (S74), and if the constraints are satisfied, proceeds to processing S80 in Fig. 7 or S90 in Fig. 8, which will be described later, depending on the type of management request. Specifically, if the management request is "create," "transfer," or "update," proceeds to S80. If the management request is "invalidate," proceeds to S90.

[0079] On the other hand, if the constraints are not satisfied, the capability management unit 24 returns information indicating denial to the first user terminal 12 (S76). In this case, the processing ends and the management request is not accepted. This makes it possible to limit management requests that use capabilities that have expired or exceeded their usage count.

[0080] (3) Processing when the request is "Create," "Transfer," or "Update" FIG. 7 is a sequence diagram following FIG. 5 or FIG. 6, showing the processing when the management request is "create," "transfer," or "update."

[0081] The capability management unit 24 transmits the option received in S52 or S72 to the policy management unit 26 (S80).

[0082] The policy management unit 26 acquires policies associated with the role identifier, capability identifier, target capability identifier, etc. from the policy storage unit 32, and checks whether the content of the options in the creation request, transfer request, or update request is within the scope of the policy (S82). The policy management unit 26 returns the check result to the capability management unit 24 (S84).

[0083] If the received confirmation result indicates that the policy is not satisfied, the capability management unit 24 returns information indicating denial to the first user terminal 12 or the second user terminal 14 (S86). In this case, the processing ends and the management request is not accepted. This makes it possible to restrict the creation, transfer, and update of capabilities that do not satisfy the policy. For example, if a context rule included in the options of a creation request does not satisfy the policy, a new capability is not created.

[0084] If the received confirmation result indicates that the policy is satisfied, the capability management unit 24 proceeds to the process of S90 in FIG. 8, which will be described below.

[0085] (4) Processing all administrative requests FIG. 8 is a sequence diagram showing the processing of a management request following FIG. 5, FIG. 6 or FIG.

[0086] If the confirmation result received in S84 indicates that the policy is satisfied, if the management request received in S52 is "invalidate," or if the constraints are satisfied in S74 and the management request is "invalidate," the capability management unit 24 operates the capability based on the request (S90). The specific processing is shown below.

[0087] In the case of a creation request, the capability management unit 24 generates a capability identifier and stores it in the database of the capability data storage unit 30 together with the content included in the options. The capability management unit 24 also updates the information on the hierarchical structure of capabilities stored in the capability data storage unit 30. When creating a capability from a role, it may be possible to specify whether to adopt the first or second pattern described above.

[0088] In the case of a delegation request, the capability manager 24 sends the identifier of the target capability to the specified user and updates the user's list of capabilities in the capability data store 30 database.

[0089] When the update request updates the body of the request, the capability management unit 24 changes the capability identifier and updates the capability data based on the content of the options. When the update request updates the conditions of the request, the capability management unit 24 updates only the capability data based on the content of the options.

[0090] In the case of an invalidation request, the capability management unit 24 deletes the capability with the identifier of the target capability from the database of the capability data storage unit 30, and also deletes all capabilities existing below it.

[0091] As described above, when a capability is directly associated with a base role, the capability management unit 24 disables the capability in response to an disable request from a user who holds the base role.

[0092] When a capability is associated with a base role via a metacapability, the capability manager 24 disables the capability only in response to an disable request from a user who holds the metacapability.

[0093] If a change to the context rule is required for each operation, the capability management unit 24 transmits a request, a capability identifier, etc. to the context management unit 22 (S92). The context management unit 22 operates the context rule based on the received information (S94), creates, modifies, or deletes the content of the rule, and returns information indicating the completion of processing to the capability management unit 24 (S96).

[0094] After completing the management process, the capability management unit 24 sends a processing completion notice indicating success to the first user terminal 12 or the second user terminal 14 of the user who sent the management request (S98), and also sends a processing completion notice to the third user terminal 16 (not shown in FIG. 1) of the target user (S100). In the case of creation, transfer, or update, the capability management unit 24 also sends the capability identifier to the target user.

[0095] Next, countermeasures against attacks on capabilities will be explained. To prevent capability tampering, capabilities are strictly managed in a database in the capability data storage unit 30 on the server. Tampering of capability content can be checked using digital signatures. Furthermore, if decentralized management is desired, the capabilities themselves may be managed decentralized using blockchain technology.

[0096] This section explains countermeasures against capability identification, leakage, and disclosure. Because users can access the system using a capability identifier, a capability identifier can be thought of as a combination of an ID and password used for authentication. Therefore, there are threats of identification through brute force attacks and leakage through social hacking. Such attacks are defended against by the commonly used multi-factor authentication. As mentioned above, this requires users to enter a capability identifier and a one-time password to access the system.

[0097] According to the embodiment, if the user's context information satisfies the context rules and the constraints on the use of capabilities are met, processing according to the request is executed, so capability-role-based access control can restrict access in unintended situations by users. Also, access rights can be granted to users across domains, allowing for decentralized management operations.

[0098] The present invention has been described above based on the embodiments. However, the embodiments are merely examples, and it will be understood by those skilled in the art that various modifications are possible in the combination of each component and each treatment process, and that such modifications are also within the scope of the present invention. [Explanation of symbols]

[0099] 10...access control device, 20...capability monitoring unit, 22...context management unit, 24...capability management unit, 26...policy management unit, 28...context rule storage unit, 30...capability data storage unit, 32...policy storage unit, 34...role-based access control unit.

Claims

1. obtaining a capability identifier and a request from a user; obtaining context information of the user, the context information including a current location of the user; comparing the context information with a context rule associated with an identifier of the capability; If the context information satisfies the context rules, performing processing according to the request if constraints on the use of the capabilities are satisfied; on the computer, the request is a usage request to access a resource using a capability or a management request for a capability; the management request is a create request to create a new capability, a transfer request to send an identifier of a capability to another user, an update request to update a capability, or a disable request to disable a capability; Capabilities are associated with a base role, When a capability is created from a base role in response to a create request, it is possible to specify whether the capability is associated with the base role directly, or whether the capability is associated with the base role via a meta-capability; If the capability is directly associated with a base role, the capability is disabled in response to a disable request by a user holding the base role; If a capability is associated with a base role via a meta-capability, the capability is disabled only in response to a disable request by the user who holds the meta-capability.

1. An access control program comprising:

2. The new capabilities created are associated with the higher capabilities, The context rules of the new capability inherit the items of the context rules of the higher capability, together with the creation request, values ​​of items of context rules to be set in the new capability are obtained from the user; 2. The access control program according to claim 1.

3. If the context rules set for a new capability do not satisfy the predefined policy, the new capability will not be created.

3. The access control program according to claim 2.

4. 1. A computer-implemented access control method, comprising: obtaining a capability identifier and a request from a user; obtaining context information of the user, the context information including a current location of the user; comparing the context information with a context rule associated with an identifier of the capability; If the context information satisfies the context rules, performing processing according to the request if constraints on the use of the capabilities are satisfied; Equipped with the request is a usage request to access a resource using a capability or a management request for a capability; the management request is a create request to create a new capability, a transfer request to send an identifier of a capability to another user, an update request to update a capability, or a disable request to disable a capability; Capabilities are associated with a base role, When a capability is created from a base role in response to a create request, it is possible to specify whether the capability is associated with the base role directly, or whether the capability is associated with the base role via a meta-capability; If the capability is directly associated with a base role, the capability is disabled in response to a disable request by a user holding the base role; If a capability is associated with a base role via a meta-capability, the capability is disabled only in response to a disable request by the user who holds the meta-capability.

1. An access control method comprising:

5. a capability monitor configured to receive a capability identifier and a request from a user and to receive context information of the user, the context information including a current location of the user; a context manager that compares the context information with a context rule associated with the identifier of the capability; a capability management unit that executes processing according to the request if the context information satisfies the context rule and if constraints on the use of the capability are satisfied; Equipped with the request is a usage request to access a resource using a capability or a management request for a capability; the management request is a create request to create a new capability, a transfer request to send an identifier of a capability to another user, an update request to update a capability, or a disable request to disable a capability; Capabilities are associated with a base role, When a capability is created from a base role in response to a create request, it is possible to specify whether the capability is associated with the base role directly, or whether the capability is associated with the base role via a meta-capability; If the capability is directly associated with a base role, the capability is disabled in response to a disable request by a user holding the base role; If a capability is associated with a base role via a meta-capability, the capability is disabled only in response to a disable request by the user who holds the meta-capability.

1. An access control device comprising:

Images