JP7779156B2 - Access control program, access control method and access control device - Google Patents

Description

Application of Article 30, Paragraph 2 of the Patent Act Proceedings of the 18th International Conference on Security and Cryptography (SECRYPT 2021), pages 819-826, July 6, 2021 18th International Conference on Security and Cryptography (SECRYPT 2021), July 7, 2021

The present invention relates to technology for controlling access to resources.

Role-based access control (RBAC) uses roles, i.e., the user's role, to grant access rights to users in systems used within the same organization. Patent Document 1 discloses a technology that, in role-based access control, rewrites roles based on the location information of the user's mobile device, making it possible to grant access rights according to the user's location.

JP 2010-55297 A

Capability-Role-Based Access Control (CRBAC) is a technology that extends role-based access control with capability-based access control. This technology uses capabilities to easily transfer access rights between members of different organizations. Furthermore, users with capabilities can create more restricted access rights based on those capabilities without administrator intervention, enabling 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 circumstances.

The objective of this invention is to provide technology that can restrict access in unintended circumstances in capability/role-based access control.

In order to solve the above problem, an access control program according to one aspect of the present invention causes a computer to execute the following steps: acquiring a capability identifier and a request from a user; acquiring 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, executing processing according to the request if constraints on the use of the capability are satisfied. The request is a use request for accessing a resource using a capability or a capability management request. The management request is a create request for creating a new capability, a transfer request for sending a capability identifier to another user, an update request for updating a capability, or an disable request for disabling a capability. Capabilities are associated with a base role, and when a capability is created from the 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 meta-capability. If a capability is directly associated with a base role, it is disabled in response to a disable request by a user holding that base role. If a capability is associated with a base role via a metacapability, it is disabled only in response to a disable request by a user holding that metacapability.

Another aspect of the present invention is an access control method. The method is a computer-implemented access control method comprising the steps of: acquiring a capability identifier and a request from a user; acquiring 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, executing processing according to 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 capability management request. 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. Capabilities are 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 meta-capability. If a capability is directly associated with a base role, it is disabled in response to a disable request by a user holding that base role. If a capability is associated with a base role via a metacapability, it is disabled only in response to a disable request by a user holding that metacapability.

Yet another aspect of the present invention is an access control device. The device includes: a capability monitoring unit that acquires a capability identifier and a request from a user and acquires context information of the user, the context information including the user's current location; 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 accordance with the request if the context information satisfies the context rule and if constraints on the use of the capability are satisfied. The request is a use request for accessing a resource using a capability or a capability management request. The management request is a creation request for creating a new capability, a delegation request for sending a capability identifier to another user, an update request for updating a capability, or an invalidation request for invalidating a capability. A capability is associated with a base role, and when a capability is created from the base role in response to a creation 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 meta-capability. If a capability is directly associated with a base role, it is disabled in response to a disable request by a user holding that base role. If a capability is associated with a base role via a metacapability, it is disabled only in response to a disable request by a user holding that metacapability.

This invention enables capability-role-based access control to restrict access in unintended circumstances.

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

Before describing the specific embodiments, we will explain the findings that form the basis of this disclosure. In order to collaborate across organizations while maintaining their organizational structure, members need to share the data required depending on the phase of the project, as well as resources such as servers, computers, and storage, with all related members, whether external or internal. In addition, members nowadays 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 granting to restrict access in unintended situations.

(1) Cross-domain access authority delegation: When members of different organizations form a team, it is necessary to grant access authority across organizations. Normally, it is necessary to create a temporary user within the same organization, i.e., domain, but this can make management complicated.

(2) Decentralized management of access rights If access rights settings are controlled by a central administrator, responding to requests from the administrator can become a bottleneck, potentially resulting in a lead time of several days.

(3) Access control in unintended situations, i.e., unintended places, times, devices, etc. Sensitive information such as personal information may be accessed from public places such as cafes, posing a risk of social hacking, such as peeking.

Using conventional role-based access control, it is difficult to satisfy the above conditions (1) and (2). Capability role-based access control can satisfy the above conditions (1) and (2), but cannot satisfy the above condition (3) because it cannot handle context information.

In this embodiment, in capability/role-based access control, if the user's context information satisfies the context rules associated with the capability identifier, and the constraints on the use of the capability are met, processing is performed according to the request. This makes it possible to handle context information in capability/role-based access control, achieving (1) to (3) above.

Figure 1 shows the 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 14.

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

The second user terminal 14 is used by a second user who accesses it using a role. Roles include, for example, administrator, developer, and viewer. A role includes a set of access rights, i.e., permissions.

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.

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 memory 28, a capability data memory 30, a policy memory 32, and a role-based access control unit 34. The access control device 10 can be configured as a server, for example.

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

When a user accesses a 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.

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, and an identifier for the device the user is currently using. The current location may include, for example, the IP address of the first user terminal 12.

The context management unit 22 manages the context rule storage unit 28, which stores context rules associated with capability identifiers as a database. Context rules include conditions for allowing access, such as location, time, and device, and are created by the user. Location conditions may include, for example, IP address.

Based on instructions received from the capability monitoring unit 20, the context management unit 22 compares the context information with the context rules associated with the capability identifier and returns the comparison results to the capability monitoring unit 20.

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

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 the processing according to the request. In the case of a usage request to access a resource, the capability management unit 24 sends the access authority (access token) to the resource to the capability monitoring unit 20, and the capability monitoring unit 20 sends the acquired access authority to the first user terminal 12. In the case of a management request to create a capability, etc., the capability management unit 24 requests the policy management unit 26 to confirm the operation content of the management request.

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

When creating a capability, the policy management unit 26 checks whether the permissions, 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 only applies to roles or capabilities below those used when the policy was set.

If the confirmation result by the policy management unit 26 indicates that the policy is met, 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 stores capability data and the hierarchical structure of the capabilities as a database.

The role-based access control unit 34 executes known role-based access control, activating and making available the role assigned to the second user who logged in using the second user terminal 14. As described below, 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). Context-based role-based access control further controls the granting of access permissions in role-based access control based on user context information.

The following describes the format of a capability. A capability includes a capability identifier, a capability body (capability_body), constraints (constraints), a context rule identifier (context_id), and receiving users (receiving_users).

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

Restrictions are restrictions on the use of capabilities, and include, for example, the expiration date of a capability, the number of times a capability can be used, the number of times permissions can be created, and the number of times a capability can be transferred. Restrictions are also called constraints.

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

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.

The characteristics of the hierarchical structure are as follows:
By specifying the identifier of a capability, all capabilities in the hierarchy below that capability (hereinafter also referred to as children) can be identified. Note that capabilities in the hierarchy above a capability are also referred to as parents.

Children only have permissions equal to or less than their parent. That is, children have permissions for each resource within the scope of their parent's permissions.

Parent constraints are inherited by children. Child constraints can be stronger than their parents. That is, children can be more restrictive than their parents. For example, if a parent has an expiration date constraint, the child can have the same expiration date or a shorter expiration date constraint.

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

Figure 2 shows a first pattern of the capability hierarchy in this embodiment. In this 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. Users who do not hold the base role 50 cannot disable the first capability 61 or any of its children.

Figure 3 shows a second pattern of the capability hierarchy in this 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.

The requests for manipulating and managing capabilities are "use," "create," "delegate," "update," and "revoke." The four requests other than "use" are collectively defined as administrative operations or management requests.

A use request (req_use) is used to access a resource using a capability.

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

A delegation request (req_delegate) is used to send existing capabilities to a specific user using a role or capability.

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

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 that increase the privileges. Examples of changes that increase privileges include adding new target resources and permissions, adding permissions to existing target resources, and relaxing conditions. A capability cannot be more privileged 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.

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 the privileges, and cannot increase the privileges of higher-level capabilities. Condition updates can be used, for example, to 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.

You can also change the conditions that weaken privileges, but in that case you will need to recursively check all lower-level capabilities. By not changing the conditions that weaken privileges, you can simplify the process.

The revocation request (req_revoke) is used to revoke a target capability using a role or capability. In this case, all children of the target capability may also be disabled.

Next, we will explain the options that are 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.

Delegation request options 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 transfer. The receiving users to add contains a list of email addresses of users to whom you want to distribute the target capability.

Update request options include the target capability identifier, additional capability body (add_capability_body), new context rule (new_context_rule), new constraints (new_constraints), and recipient 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 recipient user includes a list of email addresses of users to whom you want to distribute the capability.

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

Figure 4 is a sequence diagram showing the protocol used in the information processing system 1 of Figure 1. As an example, Figure 4 shows the process by which the first user terminal 12 accesses the server 40 (not shown in Figure 1), which is a resource.

The first user terminal 12 of the first user sends a usage request, the identifier of the capability they wish to use, and a one-time password to the capability monitoring unit 20 (S10). The capability identifier sent is for a capability that includes the identifier of the server 40 the user wishes to access.

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).

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".

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 processing 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. This makes it possible to restrict access to resources in situations unintended by the user.

If the comparison result is "OK," the capability monitoring unit 20 sends the usage request and the capability identifier to the capability management unit 24 (S22).

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 capability's usage period has expired.

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

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

If the received result indicates denial, the first user terminal 12 cannot access the server 40. This restricts access using capabilities that have expired or exceeded their usage count. This prevents unintended propagation of capabilities.

Next, the management operation protocol will be described.
(1) Management Request 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.

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 user's role (S42) and activates the session (S44) according to known processing. At this time, as described above, the role-based access control unit 34 may execute role-based access control based on the context.

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

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," processing proceeds to S80 in Figure 7, which will be described later; if the management request is "invalidate," processing proceeds to S90 in Figure 8, which will be described later.

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

(2) Management Request 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.

The first user terminal 12 sends the management request specified by the user, the identifier of the capability they wish to use, the one-time password, and options to the capability monitoring unit 20 (S60).

The capability monitoring unit 20 checks the received one-time password and, if it is correct, obtains the user's current context information (S62). The capability monitoring unit 20 sends the capability identifier and context information to the context management unit 22 (S64).

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).

If the comparison result is "NG," i.e., 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, processing ends and the management request is not accepted. This makes it possible to restrict the user's management of capabilities for context information that does not satisfy the context rules. Therefore, it is possible to restrict capability management operations by the user in unintended situations.

If the comparison result is "OK", i.e., if the context information satisfies the context rules, the capability monitoring unit 20 sends the management request, capability identifier, and options to the capability management unit 24 (S72).

The capability management unit 24 checks the constraints corresponding to the capability identifier (S74), and if the constraints are met, proceeds to processing S80 in FIG. 7 or S90 in FIG. 8, described below, 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.

On the other hand, if the constraints are not met, 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.

(3) Processing when the request is "Create,""Transfer," or "Update" Figure 7 is a sequence diagram following Figure 5 or Figure 6, showing the processing when the management request is "Create,""Transfer," or "Update."

The capability management unit 24 sends the options received in S52 or S72 to the policy management unit 26 (S80).

The policy management unit 26 retrieves policies associated with the role identifier, capability identifier, target capability identifier, etc. from the policy storage unit 32, and checks whether the options for the creation request, transfer request, and update request are within the scope of the policy (S82). The policy management unit 26 returns the check result to the capability management unit 24 (S84).

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, 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 for a creation request does not satisfy the policy, a new capability will not be created.

If the received confirmation result indicates that the policy is met, the capability management unit 24 proceeds to processing S90 in Figure 8, which is described below.

(4) Processing of All Management Requests FIG. 8 is a sequence diagram showing the processing of management requests following FIG. 5, FIG. 6 or FIG.

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 and the management request is "invalidate" in S74, the capability management unit 24 operates the capability based on the request (S90). The specific processing is shown below.

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.

In the case of a transfer request, the capability management unit 24 sends the identifier of the target capability to the specified user and updates the user list of capabilities in the database of the capability data storage unit 30.

When updating the body of an update request, the capability management unit 24 changes the capability identifier and updates the capability data based on the contents of the options. When updating the conditions of an update request, the capability management unit 24 updates only the capability data based on the contents of the options.

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 that exist below it.

As mentioned above, if 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.

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

If a change to the context rule is required for each operation, the capability management unit 24 sends a request, 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, changes, or deletes the content of the rule, and returns information indicating completion of processing to the capability management unit 24 (S96).

After completing the management process, the capability management unit 24 sends a processing completion notification indicating success to the first user terminal 12 or second user terminal 14 of the user who sent the management request (S98), and also sends a processing completion notification to the third user terminal 16 (not shown in Figure 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.

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

This section explains measures to prevent 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. As a result, there are threats of identification through brute force attacks and leakage through social hacking. Such attacks are defended against by the widely used multi-factor authentication. As mentioned above, this requires users to enter a capability identifier and a one-time password to access the system.

According to this embodiment, if the user's context information satisfies the context rules and the constraints on the use of capabilities are met, processing is performed according to the request, thereby restricting access in unintended circumstances by the user through capability-role-based access control. In addition, access rights can be granted to users across domains, allowing for decentralized management operations.

The present invention has been described above based on the embodiments. The embodiments are merely examples, and those skilled in the art will understand 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.

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 (5)

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: 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 . 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 . 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: 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: