Shulou(Shulou.com)06/03 Report--

This article focuses on "how to understand the basic concepts and architecture of the permission system". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "how to understand the basic concepts and architecture of the permission system".

Authorization process

There are three main parts in the authorization process, namely, resource management, rights and policy management, and policy enforcement.

Let's take a look at resource management:

First we need to create a resource server, then create various resources in the resource server, and finally set some scope,scope for various resources is some executable operations related to the resources.

What are resources? A resource can be a web page, a RESTful resource, a file, and so on.

For example, if we have a library resource server and the library has a book called the Myth of Man and Moon, then this book is called a resource. Next we need to define some operational scope, or strategies, for this resource. For example, only students in our school can borrow this book.

After we have defined the resources, we need to set some permissions and policies for these resources, which requires permission and policy management.

Take a look at the process of permissions and policy management:

The first is to create a policy, then to define permissions, and finally to associate permissions with policies.

A policy is defined as an operation to access certain resources or permissions, which is separate from the specific permissions. The policy only defines the circumstances under which it can be done (certain things), or in some cases can not be done (certain things). These things are the permissions created later.

For example, what you can do with a user role is a strategy.

Once the policy is defined, we can create permissions that are easy to understand, such as the rights to borrow books from the Myth of Man and Moon.

We combine policies and permissions: those who have the role of user can borrow the book Myth of Man and Moon.

There are many kinds of general policies, such as attribute-based access policy, role-based access policy, user-based access policy, context-based access policy, time-based access policy, rule-based access policy or other custom policies.

Generally speaking, the role-based access policy role-based access control (RBAC) is the most commonly used.

We assign users the appropriate roles, and then perform different permission operations according to different role policies when accessing resources.

Although RBAC is very useful and widely used, it still has the following disadvantages:

Resources and roles are strongly bound, and if we add, delete, and modify roles, all associated resources will be affected.

Changes to the role may require us to modify the code.

If your application is very large, there may be some errors when using RBAC.

RBAC is not flexible enough to achieve more fine-grained permission control.

Finally, let's take a look at the implementation of the strategy.

The execution of the policy is to actually perform the corresponding authorization work on the resource server. Generally speaking, we have a Policy Enforcement Point (PEP) in the resource server to interact with the authorization server and perform the corresponding resource operations according to the authorization information returned by the authorization server.

The architecture of the privilege system

First, take a look at a basic architecture diagram of the permission system:

There are several key components:

PAP, whose full name is Policy Administration Point, is a background page for rights management. We need such a background interface to configure and manage permissions and resources.

PDP, whose full name is Policy Decision Point, provides decision-making policies through which authorization requests are sent to the appropriate location and decisions are made according to the requested permissions.

PEP, whose full name is Policy Enforcement Point, enforces the corresponding policies in different resource servers.

The full name of PIP is Policy Information Point, and the corresponding attribute information can be obtained from it when judging and making strategies.

In the figure above, Storage is the storage and classification of data, here we mainly store four kinds of objects: resouce,scope,permission and policy.

Resource represents the object to be accessed and can be a collection of one or more objects. For example: pages in web programs and so on. Resources are protected objects and some permissions need to be configured for resources.

Each resource has a unique identifier that can represent a resource or a group of resources. For example, you can manage a bank account resource that represents and defines a set of authorization policies for all bank accounts. However, you can also use another resource called Alice's Banking Account, which represents a single resource owned by a single customer, which can have its own set of authorization policies.

Let's look at an example of resource:

In the figure above, we define different URI as resource. And gave unique names to different resource.

Scope is a series of operations on resources, such as you can read, write or edit or delete resources, which can be called scope. Of course, you can also specify an attribute in resource as the scope.

Then there is Permission, where permissions associate protected objects with policies that grant access.

For example, we have the following permissions:

X CAN DO Y ON RESOURCE Z

X represents one or more users, roles, or groups, or a combination of them.

Y represents an operation on a resource.

Z is a resource, such as the / index page.

We can create a resource-based permission:

You can also create a scope-based permission:

Policy defines the conditions that must be met to grant access to an object. Policy does not specify the object to be protected, but simply specifies the conditions that must be met to access a given object.

For example, the Policy above specifies what kind of role, what kind of client, and what kind of logic.

With a policy, we need a Policy Provider,Policy Provider that mainly provides us with an implementation of a specific type of policy.

In order to do a good job of policy evaluation, we also need a policy evaluation engine to perform policy evaluation through this engine.

In addition, as an authentication server, we also need to provide authentication services, so the best way is to provide OAuth3 or OpenID Connect token services.

We also need a Protection API for resource server to interact with the rights management service.

At this point, I believe you have a deeper understanding of "how to understand the basic concepts and architecture of the permission system". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.