CN117932628A - RBAC-based financial information system authorization management method - Google Patents

Abstract

The invention discloses a financial information system authorization management method based on RBAC, which belongs to the field of authority management, realizes authority management of users, can assign a plurality of roles to the users, supports specific security policies of various enterprises more flexibly, can respond to changes of influencing factors in the enterprises faster, can reduce operation complexity in the authorization management process, and reduces the cost of the management process. The rights possessed by the roles of the invention are not single access rules, but a rights group, which represents the scope of rights that can be possessed, under which the rights can be subdivided. After the role to which the user belongs is assigned with the permission group, the user can subdivide the designated permission from the permission range, so that different users belonging to the same role can have different permissions.

Description

RBAC-based financial information system authorization management method

Technical Field

The invention belongs to the field of authority management, and particularly relates to a financial information system authorization management method based on RBAC.

Background

With the continuous development of science and technology, in various information systems, the structure of data resources accessible by users is increasingly complex, the scale of users is increasingly large, and various information systems face the difficult problem of effectively and safely managing the data resources. How to store a large amount of data resources in an information system, reasonably control access rights of a plurality of users to the data resources, establish a user management, authorization and authentication system with perfect functions, and have important significance for ensuring the security of system data.

Financial information is the most important economic information of enterprises and public institutions, continuously, systematically, comprehensively and comprehensively reflects and supervises the business operation conditions of enterprises, and provides important basis for management and operation decision-making. The financial information system uses a computer as a main tool to collect, record, store, process and output various accounting data, and complete analysis of the financial information, provide the required financial information for users, assist them in management, prediction and decision, and improve the enterprise management level and economic benefit.

In order to ensure the data security of the financial information system, various security measures such as data encryption, identity authentication, authority management, data backup, security audit and the like can be adopted. Different security measures are directed to different aspects of the accounting data and information management process. Wherein rights management is used to determine and control what operation rights each user in the financial information system has in the system and what operations can be performed. The authority management in the authority management is the direct implementation of the related management regulation system of daily accounting work in a computer, and is the basis for ensuring that the whole authority management can normally run and meet the actual work requirement.

Disclosure of Invention

Based on the background technology, the authority management method of the financial information system based on RBAC provided by the invention realizes the authority management of the financial information system, can assign a plurality of roles for users, and is more flexible in supporting specific security policies of various enterprises.

In order to achieve the aim of the invention, the invention adopts the following technical scheme: an authorization management method of a financial information system based on RBAC, wherein the financial information system comprises a department management module, a user management module, a role management module and a right management module, and comprises the following steps:

Receiving authorization management information generated by man-machine interaction, wherein the authorization management information comprises a department management instruction, a user management instruction, a role management instruction and/or a right management instruction;

when the authorization management information comprises a department management instruction, executing the department management instruction through a department management module to add, modify and delete departments in the financial information system;

when the authorization management information comprises a user management instruction, executing the user management instruction through a user management module, and adding, modifying, deleting and distributing roles to users under departments;

when the authorization management information comprises a role management instruction, executing the role management instruction through a role management module, and adding, modifying and deleting roles of the financial information system;

when the authorization management information comprises an authorization management instruction, executing the authorization management instruction through an authorization management module, adding, modifying and deleting the color authorization, and adding, modifying and deleting the authorization in the authorization permission description corresponding to the user;

The role permission is a permission set, the permissions in the permission descriptions are subsets of the role permissions, each role is provided with a corresponding maximum associated user number and a plurality of permission descriptions, and the number of the permission descriptions is the same as the maximum associated user number; and when the role is associated with the user, distributing the permission description to the user through the financial information system.

In one possible implementation manner, before receiving the authorization management information generated by the man-machine interaction, the method further comprises: acquiring login information of an administrator, judging whether the login information of the administrator is the same as login information stored in a database in advance, if so, receiving authorization management information sent by the administrator, and if not, ending the authorization management of the financial information system.

In one possible implementation manner, after receiving the authorization management information generated by the man-machine interaction, the method further includes: judging whether the role corresponding to the user corresponding to the input authorization management information has the authority of department management, user management, role management and/or authority management, if so, carrying out authorization management according to the department management instruction, the user management instruction, the role management instruction and/or the authority management instruction, otherwise, refusing the authority management corresponding to the authorization management information.

In one possible implementation, the role allocation for the users under the departments includes:

Determining role increasing and decreasing information corresponding to a target user contained in the user management instruction; the character increasing and decreasing information comprises character sub information adding and/or character sub information deleting;

if the character increasing and decreasing information comprises the deleted character sub-information, deleting at least one character associated with the target user according to the deleted character sub-information;

if the character increasing and decreasing information comprises the increasing character sub information, determining a target character corresponding to the target user according to the increasing character sub information;

Judging whether the attribute corresponding to the target user meets the attribute requirement of the target role, if so, granting the target role for the target user, and completing the role allocation.

In one possible implementation, before granting the target role to the target user, the method further includes: judging whether the number of the target roles granted to the users reaches the upper limit, if so, refusing the grant of the target roles, otherwise, granting the target roles to the target users.

In one possible implementation, before granting the target role to the target user, the method further includes:

And acquiring an authorized role corresponding to the target user, inquiring a role mutual exclusion table from a database to judge whether the authorized role and the target role are mutually exclusive, if so, refusing the grant of the target role, otherwise, granting the target role to the target user, and the financial information system further comprises the database, wherein the role mutual exclusion table is stored in the database.

In one possible implementation, adding, modifying and deleting the color rights includes:

acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises first right adding information, first right deleting information and/or first right modifying information;

when the right management instruction comprises first right deleting information, deleting the right corresponding to the role according to the first right deleting information;

When the right management instruction comprises first right modification information, modifying the right corresponding to the role according to the first right modification information;

When the rights management instruction comprises first rights addition information, a rights mutex table is queried from a database to judge whether the rights corresponding to the first rights addition information are mutually exclusive with the original rights of the roles, if yes, the new rights of the roles are refused, and otherwise, the new rights of the roles are increased according to the first rights addition information.

In one possible implementation, adding, modifying and deleting user rights includes:

acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises second right adding information, second right deleting information and/or second right modifying information;

When the right management instruction comprises second right deleting information, deleting the right corresponding to the user according to the second right deleting information;

When the right management instruction comprises second right modification information, modifying the right corresponding to the user according to the second right modification information;

When the right management instruction comprises second right adding information, inquiring a right mutual exclusion table from a database to judge whether the right corresponding to the second right adding information is mutually exclusive with the original right of the user, if so, rejecting to add the right for the user, otherwise, performing secondary judgment; the database stores a permission mutual exclusion table;

Judging whether the authority corresponding to the second authority increasing information is the authority corresponding to the role corresponding to the user, if so, refusing to add the authority for the user, otherwise, adding the authority for the user according to the second authority increasing information.

In one possible embodiment, the method further comprises: and assigning roles or rights to the departments, and inheriting the rights corresponding to the departments or the rights corresponding to the corresponding roles by all users under the departments.

In one possible embodiment, the method further comprises: receiving an access request of a user, and determining data and functions to be accessed by the user according to the access request of the user to obtain target data and target functions;

Judging whether the authority of the user can access the target data and the target function, if so, allowing the user to access the target data and the target function, otherwise, rejecting the access request of the user.

The beneficial effects of the invention are as follows:

(1) The invention provides a financial information system authorization management method based on RBAC, which realizes authority management of users, can assign a plurality of roles for the users, supports specific security policies of various enterprises more flexibly, can respond to changes of influencing factors in the enterprises faster, can reduce operation complexity in the authorization management process, and reduces cost in the management process.

(2) The rights possessed by the roles of the invention are not single access rules, but a rights group, which represents the scope of rights that can be possessed, under which the rights can be subdivided. After the role to which the user belongs is assigned with the permission group, the user can subdivide the designated permission from the permission range, so that different users belonging to the same role can have different permissions.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

Fig. 1 is a flowchart of a financial information system authorization management method based on RBAC according to an embodiment of the present invention.

Fig. 2 is a schematic diagram of a role relationship according to an embodiment of the present invention.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

The following description of the embodiments of the present invention is provided to facilitate understanding of the present invention by those skilled in the art, but it should be understood that the present invention is not limited to the scope of the embodiments, and all the inventions which make use of the inventive concept are protected by the spirit and scope of the present invention as defined and defined in the appended claims to those skilled in the art.

In order to facilitate the understanding of the technical solution of the present invention, technical terms are first described.

The basic idea of RBAC (Role Base Access Control, role-based entitlement control system) is to complete the granting and cancellation of user entitlements by assigning and canceling roles, dividing roles according to different functional posts, encapsulating resource access permissions in roles, and users indirectly accessing and operating system resources through the assigned roles. The authorizer defines various roles according to the needs and sets proper access rights, and departments or users are assigned to different roles according to the working properties and responsibilities of the departments or users to complete rights operation. The whole access control process is divided into two parts, namely the association of the access right and the role, and the role is associated with the department or the user, so that the logical separation of the department or the user and the access right is realized. The national institute of standards and technology defines a standard RBAC model consisting of 4 sub-models, namely a basic model RBAC 0, a role classification model RBAC 1, a role restriction model RBAC 2, and a unified model RBAC 3. The role division in real work can be embodied in the authorization management of the financial information system as role division and a series of role-authority authorization and user-role authorization completion.

Role division in the RBAC model is realized by combining specific implementation modes of authorization management mainly according to the actual working environment and authority management requirements of users. Different RBAC sub-models differ in the difficulty and complexity of authorization management and implementation. According to the practical situation of the financial information system, when the number of users is small and the hierarchical structure among users is not complex and obvious, the RBAC 0 model can be adopted. For example, a small unit of financial information system users may have few roles, such as cashier, accounting, unit director. And when the number of users is large and the hierarchical structure among the users is complex, an RBAC 1 model can be adopted, the model supports inheritance relation among roles, the complexity is reduced, and the responsibility division of the real working environment can be well described. For example, in large and medium-sized enterprises, users of the financial information system may be cashiers, accounting, financial managers, financial director, and unit director, etc. Users in different positions have different rights, and a hierarchical relationship is formed between the users.

Thus, in performing role classification in the RBAC model, an important method is to refer to the setting of positions in the actual working environment for which the financial information system is oriented, while considering the working contents and properties of the user. Ideally, a particular job is of a specific content and nature, i.e. the rights it owns are explicit and singular. However, in practice, a job may have multiple jobs of different content and nature, such as a financial manager may host an information system. In performing role classification, work of different contents and properties should be classified into different roles according to the requirement of the RBAC. On the other hand, due to the hierarchical inheritance relationship between positions in the real environment, such as the financial director has all rights of the financial manager. The RBAC 1 model supports the hierarchical inheritance relationship among roles, and the hierarchical relationship among positions and the situation of multiple functions of one person can be described by adopting the role inheritance relationship of the model.

Example 1

As shown in fig. 1, a financial information system authorization management method based on RBAC, where the financial information system includes a department management module, a user management module, a role management module, and a rights management module, includes:

S1, receiving authorization management information generated by man-machine interaction, wherein the authorization management information comprises a department management instruction, a user management instruction, a role management instruction and/or a right management instruction.

S2, when the authorization management information comprises a department management instruction, the department management instruction is executed through a department management module, and departments in the financial information system are added, modified and deleted.

And S3, when the authorization management information comprises a user management instruction, executing the user management instruction through the user management module, and adding, modifying, deleting and distributing roles to users under departments.

And S4, when the authorization management information comprises a role management instruction, executing the role management instruction through the role management module, and adding, modifying and deleting the roles of the financial information system.

And S5, when the authorization management information comprises an authority management instruction, executing the authority management instruction through the authority management module, adding, modifying and deleting the color authority, and adding, modifying and deleting the authority in the authority permission description corresponding to the user.

The role permission is a permission set, the permissions in the permission descriptions are subsets of the role permissions, each role is provided with a corresponding maximum associated user number and a plurality of permission descriptions, and the number of the permission descriptions is the same as the maximum associated user number. And when the role is associated with the user, distributing the permission description to the user through the financial information system.

In the prior art, the allocation of rights to the RBAC model is not flexible enough, and it is difficult to assign a specific right to a role after it is assigned to that role. Therefore, the invention is improved based on the RBAC model, thereby enabling the authorization of the financial information system to be more flexible.

Based on RBAC model, the application provides a role-based common access control with users, and the system can store the permission description associated with the roles by the users, wherein the permission description records which permissions under the roles can be accessed by the users, and the permission description contains all the permissions of the roles in the initial state. When a user accesses the authority under a certain role, the financial information system opens the authority to the user according to the authority permission description, and under the condition that the user is ensured to be isolated from the authority, the subdivision management of the user authority can be realized, so that two users belonging to the same role can possess the authority in different ranges, and the problems in the prior art are solved.

In one possible implementation manner, before receiving the authorization management information generated by the man-machine interaction, the method further comprises: acquiring login information of an administrator, judging whether the login information of the administrator is the same as login information stored in a database in advance, if so, receiving authorization management information sent by the administrator, and if not, ending the authorization management of the financial information system.

In one possible implementation manner, after receiving the authorization management information generated by the man-machine interaction, the method further includes: judging whether the role corresponding to the user corresponding to the input authorization management information has the authority of department management, user management, role management and/or authority management, if so, carrying out authorization management according to the department management instruction, the user management instruction, the role management instruction and/or the authority management instruction, otherwise, refusing the authority management corresponding to the authorization management information.

An authorization prerequisite is mainly a prerequisite that a user should meet when being granted a certain role only when a user-role authorization is made. This and the job fulfils and qualification requirements that a person in a certain position has in a real environment, such as that the financial manager needs to take accounting, the authorization preconditions of the financial manager can be set to "must take accounting" in the authorization management. May be indicated by roles in the RBAC 2 model. Of course, this prerequisite can only constrain the roles that the user currently owns, and still fails to express more complex job conditions and qualification requirements, such as "take over accounting for more than 3 years".

Based on the authorization preconditions, performing role allocation on users under departments, including:

and determining the target user and role increasing and decreasing information corresponding to the target user contained in the user management instruction. The character increasing and decreasing information comprises adding character sub information and/or deleting character sub information.

And if the character increasing and decreasing information comprises the deleted character sub-information, deleting at least one character associated with the target user according to the deleted character sub-information.

And if the character increasing and decreasing information comprises the increasing character sub information, determining a target character corresponding to the target user according to the increasing character sub information.

Judging whether the attribute corresponding to the target user meets the attribute requirement of the target role, if so, granting the target role for the target user, and completing the role allocation.

In one possible implementation, before granting the target role to the target user, the method further includes: judging whether the number of the target roles granted to the users reaches the upper limit, if so, refusing the grant of the target roles, otherwise, granting the target roles to the target users.

The role cardinality indicates the limit on the number of users a role can grant. In real life, certain roles can only be granted to one user, e.g. the financial director can only be one person, and the cardinality of the role is 1. While some roles may be awarded to multiple users, such as multiple accounting and cashes, as might be possible in a financial department, the cardinality of these two roles is greater than 1. Setting the role cardinality avoids the spread of rights so that important rights can only be obtained by limited people.

The static responsibility and authority separation can solve potential benefit conflicts in the role system, and avoid users exceeding the reasonable authority level of the current position. In short, to avoid conflicts between two roles, such as accounting and cashing, a company generally does not allow the same person to double, so assigning roles to the same person should be prohibited. The constraint may be implemented using role mutual exclusion.

Based on the static responsibility separation, before granting the target role to the target user, the method further comprises the following steps:

And acquiring an authorized role corresponding to the target user, inquiring a role mutual exclusion table from a database to judge whether the authorized role and the target role are mutually exclusive, if so, refusing the grant of the target role, otherwise, granting the target role to the target user, and the financial information system further comprises the database, wherein the role mutual exclusion table is stored in the database.

In role-rights delegation, two or more rights mutually exclusive are avoided from delegating to the same role. For example, in the financial department, approval of travel fees and reimbursement authority are mutually exclusive and cannot be given to the same role.

Static responsibility and authority mutual exclusion mainly meets the incompatible job requirements in financial work, such as authorizing certain economic service and executing job separation of the service, wherein personnel required to decide or approve material purchase cannot simultaneously serve as the buyer, and personnel required to fill out sales invoices cannot serve as the auditor.

Based on authority mutual exclusion, adding, modifying and deleting the color authorities, including:

And acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises first right adding information, first right deleting information and/or first right modifying information.

When the right management instruction comprises first right deleting information, deleting the right corresponding to the role according to the first right deleting information.

When the right management instruction comprises first right modification information, modifying the right corresponding to the role according to the first right modification information.

When the rights management instruction comprises first rights addition information, a rights mutex table is queried from a database to judge whether the rights corresponding to the first rights addition information are mutually exclusive with the original rights of the roles, if yes, the new rights of the roles are refused, and otherwise, the new rights of the roles are increased according to the first rights addition information.

In one possible implementation, adding, modifying and deleting user rights includes:

and acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises second right adding information, second right deleting information and/or second right modifying information.

And when the right management instruction comprises the second right deleting information, deleting the right corresponding to the user according to the second right deleting information.

When the right management instruction comprises second right modification information, modifying the right corresponding to the user according to the second right modification information.

And when the right management instruction comprises the second right adding information, inquiring a right mutual exclusion table from a database to judge whether the right corresponding to the second right adding information is mutually exclusive with the original right of the user, if so, rejecting to add the right for the user, otherwise, performing secondary judgment. And the database stores a permission mutual exclusion table.

Judging whether the authority corresponding to the second authority increasing information is the authority corresponding to the role corresponding to the user, if so, refusing to add the authority for the user, otherwise, adding the authority for the user according to the second authority increasing information.

In one possible embodiment, the method further comprises: and assigning roles or rights to the departments, and inheriting the rights corresponding to the departments or the rights corresponding to the corresponding roles by all users under the departments.

In one possible embodiment, the method further comprises: and receiving an access request of the user, and determining data and functions to be accessed by the user according to the access request of the user to obtain target data and target functions.

Judging whether the authority of the user can access the target data and the target function, if so, allowing the user to access the target data and the target function, otherwise, rejecting the access request of the user.

Optionally, with the use of the financial information system, the roles allocated by the administrator are more and more, especially for medium-sized and large-sized enterprises, the involved posts and the authorities of the posts are more and more, and some similar roles inevitably appear, so that not only is the burden increased for the operation of the system, but also the management efficiency of the administrator is reduced, and therefore, the implementation provides a similar role optimization method.

The similar role optimization method comprises the following steps:

A1, arbitrarily taking out one role from the financial information system to obtain a target role and a residual role pool.

A2, based on the target role, obtaining the similarity between the target role and any one of the residual roles in the residual role pools, traversing the residual roles in all the residual role pools, and obtaining the similarity between the target role and all other residual roles in the residual role pools.

A3, selecting the rest roles with the similarity smaller than the threshold value as the similar roles of the target roles, and obtaining similar role pairs.

And A4, judging whether the residual roles exist in the residual role pool, if so, taking out one residual role from the residual role pool, taking the residual role as a new target role, returning to the step A2, and otherwise, entering the step A5.

And A5, judging whether the same similar role pairs exist, if so, only reserving one similar role pair for the same similar role pair, entering a step A6, and if not, directly entering the step A6.

And A6, combining each similar role pair into a new role, taking all rights of the similar role pair as rights of the new role, taking the maximum number of users corresponding to the similar role pair as the maximum number of users of the new role, and distributing rights permission description with the same number as the maximum number of users for the new role.

It should be noted that, if the user corresponds to the similar role, the authority corresponding to the user is recorded in the authority permission description.

The financial information system authorization management method based on RBAC provided by the invention realizes authority management of users, can assign multiple roles to users, supports specific security policies of each enterprise more flexibly, can respond to changes of influencing factors in the enterprise faster, can reduce operation complexity in the authorization management process, and reduces cost in the management process.

The rights possessed by the roles of the invention are not single access rules, but a rights group, which represents the scope of rights that can be possessed, under which the rights can be subdivided. After the role to which the user belongs is assigned with the permission group, the user can subdivide the designated permission from the permission range, so that different users belonging to the same role can have different permissions.

Example 2

This example was made on the basis of example 1.

As shown in fig. 2, each role is similar to the upper and lower relationship of the position of the real work, and different roles form an inheritance relationship according to the upper and lower position relationship, namely, the upper role inherits all rights of the lower role. However, in an actual working environment, not all rights of the subordinate character are inherited by the superordinate character, because the financial information system is different from other information systems. Two concepts, private rights and public rights, are thus introduced here. The private authority is exclusive to the role, the superior role cannot inherit the authority, and the corresponding public authority is inheritable by the superior role. The two concepts are introduced to consider the situation that the cost accounting has accounting authority, but the authority cannot be owned by the accounting owner, and the accounting inquiry authority of the cost accounting can be owned by the accounting owner. Thus, the accounting authority is the private authority of the cost accounting role, and the query authority is the public authority.

The financial information system sets a most basic role of "financial staff", which has the most basic rights. And multiple accounting and cashing roles inherit the role and have all the rights of the role. On this basis, each different role has its own different rights. Such as "cost accounting" having "cost accounting" private rights and "query cost accounting" public rights, and cash register having "cash diary registration" private rights and "query cash diary" public rights, etc. The accounting director and the cashier director respectively serve as superior roles of accounting and cashier, and inherit public rights of accounting and cashier below the accounting director and the cashier respectively. The "finance manager" and the "master accountant" on the same form an inheritance relationship. As shown in table 1, the authorization preconditions, role cardinality, and static responsibility separation for each role are presented.

TABLE 1

The above table shows three authorization constraints, where "|" indicates a or relationship between the preceding and following roles, a role radix of 1 indicates that the role can only be assigned to one user, and a role radix of n indicates that n people can be assigned.

The authorization preconditions in the table indicate that a user must be required to have the role specified by the precondition when the role is granted to that user. And the static responsibility separation indicates that the listed role of the column and the role corresponding to the row cannot be granted to the same person. Such as BC, CC and MC, cannot be granted to one user at a time.

Rights mutex is not specifically listed and is exemplified by a CA that cannot have both "expense audit" and "expense reimbursement" rights, and thus may be expressed in the authorization constraints as "expense audit |expense reimbursement", i.e., only one of the two rights is selected.

In actual implementation, one role-related authorization constraint may be expressed as: (authorization preconditions, role cardinality, static responsibility separation, authority mutual exclusion) such a 4-tuple. Authorization constraints such as CA may be expressed as (FE, n, BC|CC, expense audit|expense reimbursement.

It should be noted that any method using the inventive concept should be within the scope of the present invention. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It is to be understood that the invention is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the invention is limited only by the appended claims.

Claims (10)

1. An authorization management method of a financial information system based on RBAC, wherein the financial information system comprises a department management module, a user management module, a role management module and a right management module, and is characterized by comprising the following steps:

Receiving authorization management information generated by man-machine interaction, wherein the authorization management information comprises a department management instruction, a user management instruction, a role management instruction and/or a right management instruction;

when the authorization management information comprises a department management instruction, executing the department management instruction through a department management module to add, modify and delete departments in the financial information system;

when the authorization management information comprises a user management instruction, executing the user management instruction through a user management module, and adding, modifying, deleting and distributing roles to users under departments;

when the authorization management information comprises a role management instruction, executing the role management instruction through a role management module, and adding, modifying and deleting roles of the financial information system;

when the authorization management information comprises an authorization management instruction, executing the authorization management instruction through an authorization management module, adding, modifying and deleting the color authorization, and adding, modifying and deleting the authorization in the authorization permission description corresponding to the user;

The role permission is a permission set, the permissions in the permission descriptions are subsets of the role permissions, each role is provided with a corresponding maximum associated user number and a plurality of permission descriptions, and the number of the permission descriptions is the same as the maximum associated user number; and when the role is associated with the user, distributing the permission description to the user through the financial information system.

2. The RBAC-based financial information system authorization management method of claim 1, further comprising, prior to receiving authorization management information generated by human-machine interaction: acquiring login information of an administrator, judging whether the login information of the administrator is the same as login information stored in a database in advance, if so, receiving authorization management information sent by the administrator, and if not, ending the authorization management of the financial information system.

3. The RBAC-based financial information system authorization management method of claim 1, further comprising, after receiving authorization management information generated by human-machine interaction: judging whether the role corresponding to the user corresponding to the input authorization management information has the authority of department management, user management, role management and/or authority management, if so, carrying out authorization management according to the department management instruction, the user management instruction, the role management instruction and/or the authority management instruction, otherwise, refusing the authority management corresponding to the authorization management information.

4. The RBAC-based financial information system authorization management method according to claim 1, wherein assigning roles to users under a department comprises:

Determining role increasing and decreasing information corresponding to a target user contained in the user management instruction; the character increasing and decreasing information comprises character sub information adding and/or character sub information deleting;

if the character increasing and decreasing information comprises the deleted character sub-information, deleting at least one character associated with the target user according to the deleted character sub-information;

if the character increasing and decreasing information comprises the increasing character sub information, determining a target character corresponding to the target user according to the increasing character sub information;

Judging whether the attribute corresponding to the target user meets the attribute requirement of the target role, if so, granting the target role for the target user, and completing the role allocation.

5. The RBAC-based financial information system authorization management method of claim 4, further comprising, prior to granting the target role to the target user: judging whether the number of the target roles granted to the users reaches the upper limit, if so, refusing the grant of the target roles, otherwise, granting the target roles to the target users.

6. The RBAC-based financial information system authorization management method of claim 4, further comprising, prior to granting the target role to the target user:

And acquiring an authorized role corresponding to the target user, inquiring a role mutual exclusion table from a database to judge whether the authorized role and the target role are mutually exclusive, if so, refusing the grant of the target role, otherwise, granting the target role to the target user, and the financial information system further comprises the database, wherein the role mutual exclusion table is stored in the database.

7. The RBAC-based financial information system authorization management method of claim 1, wherein adding, modifying, and deleting rights to a color comprises:

acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises first right adding information, first right deleting information and/or first right modifying information;

when the right management instruction comprises first right deleting information, deleting the right corresponding to the role according to the first right deleting information;

When the right management instruction comprises first right modification information, modifying the right corresponding to the role according to the first right modification information;

When the rights management instruction comprises first rights addition information, a rights mutex table is queried from a database to judge whether the rights corresponding to the first rights addition information are mutually exclusive with the original rights of the roles, if yes, the new rights of the roles are refused, and otherwise, the new rights of the roles are increased according to the first rights addition information.

8. The RBAC-based financial information system authorization management method of claim 1, wherein adding, modifying, and deleting user rights comprises:

acquiring a right management instruction generated by man-machine interaction, wherein the right management instruction comprises second right adding information, second right deleting information and/or second right modifying information;

When the right management instruction comprises second right deleting information, deleting the right corresponding to the user according to the second right deleting information;

When the right management instruction comprises second right modification information, modifying the right corresponding to the user according to the second right modification information;

When the right management instruction comprises second right adding information, inquiring a right mutual exclusion table from a database to judge whether the right corresponding to the second right adding information is mutually exclusive with the original right of the user, if so, rejecting to add the right for the user, otherwise, performing secondary judgment; the database stores a permission mutual exclusion table;

Judging whether the authority corresponding to the second authority increasing information is the authority corresponding to the role corresponding to the user, if so, refusing to add the authority for the user, otherwise, adding the authority for the user according to the second authority increasing information.

9. The RBAC-based financial information system authorization management method of claim 1, further comprising: and assigning roles or rights to the departments, and inheriting the rights corresponding to the departments or the rights corresponding to the corresponding roles by all users under the departments.

10. The RBAC-based financial information system authorization management method of claim 9, further comprising: receiving an access request of a user, and determining data and functions to be accessed by the user according to the access request of the user to obtain target data and target functions;

Judging whether the authority of the user can access the target data and the target function, if so, allowing the user to access the target data and the target function, otherwise, rejecting the access request of the user.