This article is far from sufficient to discuss permission management strategies based on role concepts and mainly on role-based mechanisms. A better way to manage permissions will also be discussed.

What is a Role? What is a role

When people think of permission management for programs, they often think of roles. A role is an entity that represents a set of behaviors or responsibilities that define what you can and cannot do within a software system. User accounts are often associated with roles, so what a user can “do” in a software system depends on the roles associated with it.

For example, if a user logs in with an account associated with the “project administrator” role, that user can do everything a project administrator can do — listing applications in the project, managing project team members, generating project reports, and so on.

In this sense, a role is more of a concept of behavior: it represents what a user can do in the system.

Role-based Access Control Role-based Access Control

Since roles represent the concept of actions that can be performed, it is logical to use roles in software development to control access to software functions and data. As you might have guessed, this approach to Access Control is called Role-based Access Control, or RBAC.

There are two types of RBAC access control that are being used in practice: implicit and explicit.

There are still a large number of software applications that use implicit access control. But I can definitely say that the display access control approach is more suitable for current software applications.

Implicit Access Control indicates Implicit Access Control

As mentioned earlier, roles represent a set of actions that can be performed. But how do we know which executable actions are associated with a role?

The answer is: in most current applications, you don’t know exactly what actions a character is associated with. You probably know this already (you know that a user with an “administrator” role can lock a user account and configure the system; A user associated with the role of “consumer” can purchase goods on the site), but these systems do not clearly define what actions a role involves.

In the case of “project manager”, there is no clear definition of what “project manager” can do. It is just a string noun. Developers often write this term into their programs for access control. For example, to determine whether a user can view a project report, a programmer might code the following reference:

Code block 1. Implicit role-based permission control:

If (user.hasRole("Project Manager")) {// Display report button} else {// do not display button <strong>}Copy the code

In the example representative above, the developer determines whether the user has a project manager role to display the View project report button. Note that the code above does not explicitly define the executable actions of the project manager role. It simply assumes that a user associated with the project manager role can view the project report, and developers write if/else statements based on this assumption.

Brittle Security Policy Indicates a Brittle Security Policy

Access controls like the one above are very fragile. Even a small change in permission requirements can cause the code above to need to be rewritten.

For example, let’s say that one day the development team is told, “Oh, by the way, we need a ‘department administrator’ role who can also view project reports. Please do this.”

In this case, the developer needs to find the above code block and modify it to:

Block 2. Modified implicit role-based permission controls:

If (user. HasRole (" Project Manager ") | | user. HasRole (" Department Manager ")) {/ / show report button} else {/ /} does not display the buttonCopy the code

Then, the developer needs to update his test cases, recompile the system, and perhaps revisit the software quality control (QA) process before redeploying to live. All because of a minor change in permission requirements!

What if the demander comes back to you later and says we have another role to view the report, or the previous requirement that “department administrator can view the report” is no longer needed?

What if the demander needs to create and delete roles dynamically so that they can configure them themselves?

As in the case above, this implicit (static string) role-based access control approach is inadequate. Ideally, no code needs to be modified if permission requirements change. How do you do that?

Explicit Access Control: Explicit Access Control is A Better Way

As we can see from the above examples, implicit access control can be a heavy burden to program development when permission requirements change. It would be nice if there were a way to meet permission requirements when they changed without having to modify the code. It is understood that, even on a running system, you can modify permissions without affecting end users. When you find some bad or dangerous security policy, you can quickly change the policy configuration and still have your system working, without refactoring the code and redeploying the system.

How to achieve the above ideal effect? We can do this by explicitly (explicitly) defining what we can do in the application.

Go back to the example of implicit permission controls above and think about the ultimate purpose of the code. What kind of controls are they ultimately intended to do?

Ultimately, this code is about protecting resources (project reports) and defining what a user can do (view/modify) with those resources. When we break down permission access control to this primitive level, we can express permission control policies in a more granular (and flexible) way.

We can modify the above code block to make access control more efficient with resource-based semantics:

Block 3. Explicit permission controls:

If (user.ispermitted ("projectReport:view:12345")) {if (user.ispermitted ("projectReport:view:12345")) {Copy the code

In the example above, we can clearly see what we are controlling. Don’t worry too much about the colon-separated syntax, this is just an example, but the above statement explicitly says “show the project report button if the current user is allowed to view the project report number 12345.” That is, we explicitly state the specific actions that a user account can perform on a resource instance.

How is this better? Why is this better

The main difference between the last sample code block above and the previous code is that the last code block is based on what is protected, not who might be able to do what. Seemingly simple differences, but the latter has profound implications for system development and deployment:

  • Less code refactoring: We control permissions based on the system’s functionality (its resources and operations on them), and accordingly, once the system’s functional requirements are determined, there is relatively little change to them over time. It is only when the functional requirements of the system change that permission code changes are involved. For example, to view project reports as mentioned above, explicit permission control does not require code refactoring for different users/roles as traditional implicit RBAC permission control does; As long as this feature exists, explicit permission control code does not need to be changed.
  • Resources and operations are more intuitive: Protecting resource objects and controlling operations on resource objects are more in line with people’s thinking habits. Because of this intuitive way of thinking, object-oriented editing ideas and REST communication model become very successful.
  • The security model is more resilient: the sample code above does not specify which users, groups, or roles can do what to resources. This means that it supports the design of any security model. For example, actions (permissions) can be assigned directly to users, or they can be assigned to a role and then associated with users, or multiple roles can be associated with groups, and so on. You can completely customize the permission model for your application.
  • External security policy management: Because the source code only reflects resources and behaviors, not users, groups, and roles, the association of resources/behaviors with users, groups, and roles can be done through external modules or specialized tools or administrative consoles. This means that developers don’t have to spend time modifying code when permission requirements change, and business analysts or even end users can modify permission policy configurations through appropriate administrative tools.
  • Make changes at runtime: Because based on resource access control code does not rely on the body of the behavior (such as a group, role, coloring), you are not the body of the behavior character name down in the code, so you can even when the program is run by changing the subject to the operation of the resources that a number of ways, through configuration way can deal with authority, the change of demand There is no need to refactor code as there is with the implicit RBAC approach.

The New RBAC: Resource-based Access Control Resource-based permission management

For the many benefits listed above, I focus on the flexible permissions model that this explicit mechanism gives us.

If you still want to preserve or emulate traditional role-based permission access control, you can assign permissions (actions that can be performed) directly to a role. In this case, you are still using role-based permission access control (the difference is that you need to explicitly define permissions in roles, rather than using character strings implicitly to control permissions).

But with this new model, it’s no longer about roles. You can assign permissions directly to users, groups, or any other object you wish.

Because of the above benefits of explicit, resource-based Access Control, it might be possible to give RBAC a new definition: “Resource-based Access Control.” Just a thought 🙂

Real World Example: Apache Shiro

If you are wondering if there is a resource-based permission control framework used by multiple systems in the real world, you can check out Apache Shiro. It is a modern permission management framework for the Java platform. With its concept of Permission, Shiro well supports resource-based Permission access control.

Of course, you don’t need Shiro to understand some of the concepts discussed in this article, but Shiro is helpful in understanding the concepts and examples discussed in this article.

Reference:

  • Stormpath.com/blog/new-rb…
  • Apache Shiro 1.2.x Reference Manual

Original link:

  • Developer.aliyun.com/article/471…

About us

“Longgui Technology”Is a focus on low code enabling enterprise level information service provider. The core founder team came from green Alliance Security, Red Hat open source operating system, well-known game playing crab technology, well-known open source community and other experts jointly founded.

“Longgui Technology” is committed to enabling every enterprise in China to have their own automated office operating system, to help enterprises or governments embrace Cloud Native First strategy, to help customers build a modern IT infrastructure centered on “identity and application”! So as to realize “digital transformation” and “industrial production of software industry”!

Main products: ArkOS ARK operating system: an enterprise-level office automation operating system, combined with self-developed low code application development platform, to build an industrial ecosystem, focusing on creating an integrated full-stack cloud native platform for all kinds of enterprises and organizations. System built-in applications include: ArkID unified identity authentication, ArkIDE, ArkPlatform, App Store and other products. Up to now, the company has obtained 15 software Copyrights, 2 invention patents, and in November 2020, Beijing Haidian District Zhongguancun National high-tech enterprise certification.

Related links:

Website: www.longguikeji.com/

Documents: docs.arkid.longguikeji.com/

Open source code warehouse address:

github.com/longguikeji

gitee.com/longguikeji

Article history

  1. The landing wheel? You’re still building it?
  2. Enterprise single sign-on – foundation of information system construction
  3. Are you ready for telecommuting?
  4. Enterprise informatization, how to count?
  5. The dragon to science and technology | some speculation about the future
  6. The dragon is the future of science and technology | enterprise office automation
  7. The dragon to science and technology | software costs down