About the understanding of RBAC (Role-base Access Control) (goto)

Role-based access controls (Role-base access control)

There are two types of RBAC access control methods that are being used in practice: implicit (fuzzy) and display (explicit) mode.

Today there are still a lot of software applications that use implicit access control methods. The access control method displayed is more suitable for the current software application.

Implicit access control

Implicit access control is not to add specific permissions to the role of the operation, but to the user to add an identity, tell the system I belong to this role, as long as the system allows the role of the resources to operate, I have permission to operate.

For example, I now have two roles for a system, namely "Super Administrator", "Project manager", "Ordinary user";

Users are: root, Zhangsan;

Assign roles to the above three users: Root gives the "Super admin" role/Zhangsan to the "Normal user" role

Then I now have a function to modify the user password, this function can only be the "Super administrator" role of the user to operate, then the specific code of the implicit access control will be as follows:

if (Currentuser.hasrole ("Super admin")) {    //have permission to operate}else{   //Do not have permission to operate}

The above code says that if the current Access user object is subordinate to the "Super administrator" role, then there is the right to modify the user password operation, otherwise there is no permission to operate.

This permission action does not explicitly tell the system what the role can do, but the programmer knows what the role can do, relying on if else in the program to determine what these roles can do.

If you add a "normal user" at this time can also modify the user password permissions, then this time the code should be changed to the following:

if (Currentuser.hasrole ("Super admin") | | currentuser.hasrole ("normal user")) {    //have permission to operate}else{   //no permission to operate}

This kind of authority management is not very good, just because of a small permission to change the requirements, you need to change the code, recompile, deploy ...

If you let the project administrator also have this permission, you have to modify the ...

Therefore, the following explicit access control is recommended.

Explicit access control

Explicit access control is an explicit means of telling the system what these roles can do, so that users who belong to the role have the appropriate permissions.

For example: "Super admin" {"Create user", "Modify User password", "Delete user"} permissions

Then the code that modifies the user's password is as follows:

Gets the role of the current user and then uses the role to determine if there are "permissions to modify user passwords" if (Currentuser.getrole (). Ispermission ("Modify user password")) {   //have permission to operate}else{    // No permissions to operate  }

Assuming I'm going to get rid of the Super Administrator's "Modify user password" permissions, then I just need to modify the permissions of the configuration file, without the need to modify the Code section.

Therefore, it is recommended to use explicit access control.

Reference: http://www.thinksaas.cn/group/topic/150841/

Understanding of RBAC (Role-base Access Control) (GO)