CN111917739A - RESTful specification-based ACBC (Access control Block) authority management model - Google Patents

Abstract

The invention discloses an ACBC (Access control Block) authority management model based on RESTful specification, which consists of a link access module, a user auditing module, a type identification module, a time identification module and a department identification module, wherein the user auditing module, the type identification module, the time identification module and the department identification module are in a parallel structure. The RESTful specification-based ACBC permission management model can be used for setting a plurality of different subjects and different objects according to actual requirements to meet various or wide or detailed permission restrictions, and does not need to care whether users of the existing roles are influenced like RBAC permission management, and the users are completely separated from roles and permission relations.

Description

RESTful specification-based ACBC (Access control Block) authority management model

Technical Field

The invention relates to the technical field of authority management, in particular to an ACBC authority management model based on RESTful specification.

Background

The Role-Based rights management model of RBAC (Role-Based Access Control) is a very widely used rights management means at present. Has wide application in various industries and fields. The common RBAC model performs authority control through authority, roles, users and the relationship among the three. Complete authority management is usually implemented by using 5 tables, namely a user table, a role table, an authority table, a user role table and a role authority table.

The Attribute-Based Access Control of the ABAC (Attribute-Based Access Control) is more in the development stage, and the actual application is not much because the implementation is more complicated compared with the RBAC.

The existing RBAC (role-based Access control) authority management model has the common problems that the granularity is not fine enough, and certain specific operations cannot be accurately limited. For example, a role has a right to view company personnel information, but the role is required to not view information of certain individual personnel at the same time, similar requirements are very common, but the role is not particularly convenient to implement in a conventional RBAC model, in other words, the granularity of the common RBAC model is coarse, and the role is not well applicable to places requiring precise right management

Therefore, the patent provides an ACBC authority management model based on RESTful specification.

Disclosure of Invention

The present invention aims to provide an ACBC rights management model based on RESTful specification to solve the above problems in the background art.

In order to achieve the purpose, the invention provides the following technical scheme: the authority management model is composed of a link access module, a user auditing module, a type identification module, a time identification module and a department identification module, and the user auditing module, the type identification module, the time identification module and the department identification module are in a parallel structure.

Preferably, the link access module is configured to access the goods link and send the GET request using the goods link.

Preferably, the user auditing module is used for auditing whether the user has the accessed user in the user table.

Preferably, the type identification module is used for checking whether the accessed employee type is a formal employee.

Preferably, the time identification module is configured to determine whether the transmission time of the request is in a range of 8: 00 to 17: during the 00 period.

Preferably, the department identification module is used for identifying whether the employee belongs to the market department.

Preferably, the user can inquire the commodity information only when the user audit module, the type identification module, the time identification module and the department identification module are satisfied.

Preferably, when any one of the user audit module, the type identification module, the time identification module and the department identification module is not satisfied, an error is returned to prompt that no access is authorized.

Preferably, the verification process of the rights management model is as follows:

whether the user exists in the user list or not;

whether the employee type is official or not;

whether the request is sent at time 8: 00 to 17: within a period of 00 hours;

whether the employee belongs to the market division;

if the 4 conditions are met, returning commodity information;

if any one of the two items is not satisfied, returning to report an error and prompting that no access is available.

Compared with the prior art, the invention has the following beneficial effects: the RESTful specification-based ACBC permission management model can be used for setting a plurality of different subjects and different objects according to actual requirements to meet various or wide or detailed permission restrictions, and users who need to be related to the existing roles or not are not influenced like RBAC permission management, and are completely separated from roles and permission relations; the adopted authority setting scheme and the authority verification process can carry out authorization very quickly and accurately. The control fineness of the ABAC is difficult to be achieved by the RBAC model (in the above case, for example, if the RBAC model is used for implementation, a role needs to be additionally defined for the rule, and if the role is only applicable to a small part of people, the authorization work is also quite cumbersome). In the RBAC, if i need to implement fine-grained resource management or the correspondence between the subject and the object changes frequently, it is difficult for the administrator to operate and a problem easily occurs (the RBAC needs to define different roles for different permissions and also needs to configure roles for users), where a solution that is often adopted is to create roles that should not exist. However, in the ABAC, the management object of the administrator is reduced to policy, that is, only the access control is processed, only the rule itself is managed, and the method is closer to the real use scene than the role management.

Drawings

FIG. 1 is a schematic diagram of the workflow of the present invention;

FIG. 2 is a schematic diagram of a work user table structure according to the present invention;

FIG. 3 is a schematic diagram of a merchandise table structure according to the present invention;

FIG. 4 is a diagram illustrating a structure of a permission table according to the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Referring to fig. 1, the present invention provides a technical solution: a permission management model of an ACBC (Access control Block) based on RESTful specification is composed of a link access module, a user auditing module, a type identification module, a time identification module and a department identification module, wherein the user auditing module, the type identification module, the time identification module and the department identification module are in a parallel structure.

The link access module is used for accessing the commodity link and sending the GET request by using the commodity link.

The user auditing module is used for auditing whether the user has the accessed user in the user list.

The type identification module is used for checking whether the accessed employee type is a formal employee.

The time identification module is used for judging whether the sending time of the request is 8: 00 to 17: during the 00 period.

The department identification module is used for identifying whether the employee belongs to the market department.

The user can inquire the commodity information only when the user audit module, the type identification module, the time identification module and the department identification module are met.

And if any one of the user audit module, the type identification module, the time identification module and the department identification module is not satisfied, returning to report an error and prompting that no access is authorized.

Since the RESTful specification specifies to some extent the format of http requests, the attributes, Subject, Object, Operation, Environment Conditions and Policy in the ABAC used in this patent are more clearly defined.

Subject: system user

Object: the accessed resource, and the URI is the resource in the RESTful specification, and thus is also referred to herein as the URI.

Environmental Conditions, namely, peripheral Conditions such as time, safety level, operation Environment (production Environment or test Environment) and the like.

Attribute of Subject \ Object \ Environment Conditions, which can also be understood as the fields of the above objects, such as: the user has the related attributes of user name, age, whether to be officially employee, contact information, and the like, and the user includes: the file on the server has the attributes of file name, file size, file path and the like;

operation: and (4) operating by combining RESTful specifications, namely requesting methods GET, POST, PUT, DELETE and the like.

And Policy: rules, i.e. authorization logic or access rules.

With the above definitions, a relatively complex authorization rule can be formulated. Such as: official employees of the company can access files under a certain path in the shared server through the company local area network during working hours. The following is specified in this authorization rule

User and with Attribute: official employee

Object sharing a Path (URI) in the Server

Environment Conditions that work hours use corporate LANs

Operation GET request

The authority verification process also verifies whether all the rules meet the requirements one by one, and when any one of the rules does not meet the requirements, the request is rejected.

The following is an example of an application: please refer to fig. 2, fig. 3 and fig. 4

The link of more than three functions sends a GET request, and when commodity price information is inquired, the permission verification process is as follows:

1. whether there are three users on the user exterior and interior

2. Whether the employee type of Zhang III is formal

3. Whether the request is sent at time 8: 00 to 17: within a period of 00

If all the above 3 conditions are satisfied, commodity information is returned.

If any one of the two items is not satisfied, returning to report an error and prompting that no access is available.

For example, Zhang III inquires the price of the commodity at 7 am, corresponding information cannot be obtained.

The tee is connected with the following parts by the chain 10: 00, sending a POST request, adding price information of the trusted commodity, and carrying out the following authority verification process:

1. whether there are three users on the user exterior and interior

2. Whether the employee type of Zhang III is formal

3. Whether the request is sent at time 8: 00 to 17: within a period of 00

4. Whether Zhang III belongs to the market department

And the operation of the third page is effective, and the data is stored in a database.

That lie four performs the same operation is not operable, since lie four does not belong to the market sector.

Rules like this can be set up for different subjects, and for different subjects, according to actual needs, to satisfy various or broad, or detailed permission restrictions, without the need to relate to existing roles-those users will be affected, as in RBAC permission management, and completely separate from role and permission relationships.

Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes, modifications, substitutions and alterations can be made in these embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the appended claims and their equivalents.

Claims (9)

1. The ACBC authority management model based on RESTful specification is characterized by comprising a link access module, a user auditing module, a type identification module, a time identification module and a department identification module, wherein the user auditing module, the type identification module, the time identification module and the department identification module are in a parallel structure.

2. The RESTful specification-based ACBC rights management model of claim 1, wherein: the link access module is used for accessing the commodity link and sending the GET request by using the commodity link.

3. The RESTful specification-based ACBC rights management model of claim 1, wherein: the user auditing module is used for auditing whether the user has the accessed user in the user table.

4. The RESTful specification-based ACBC rights management model of claim 1, wherein: the type identification module is used for checking whether the accessed employee type is a formal employee.

5. The RESTful specification-based ACBC rights management model of claim 1, wherein: the time identification module is used for judging whether the sending time of the request is 8: 00 to 17: during the 00 period.

6. The RESTful specification-based ACBC rights management model of claim 1, wherein: the department identification module is used for identifying whether the employee belongs to the market department.

7. The RESTful specification-based ACBC rights management model of claim 1, wherein: the user can inquire the commodity information only when the user audit module, the type identification module, the time identification module and the department identification module are satisfied.

8. The RESTful specification-based ACBC rights management model of claim 1, wherein: and if any one of the user auditing module, the type identification module, the time identification module and the department identification module is not satisfied, returning to report an error and prompting that no access is authorized.

9. The RESTful specification-based ACBC rights management model of claim 1, wherein: the verification process of the authority management model is as follows:

whether the user exists in the user list or not;

whether the employee type is a formal employee;

whether the request is sent at time 8: 00 to 17: within a period of 00 hours;

whether the employee belongs to the market division;

if the 4 conditions are met, returning commodity information;

if any one of the two items is not satisfied, returning to report an error and prompting that no access is available.

Images