Implementing permission models with Authing

The meaning of authorization

In the general field, authorization is the process of leaders achieving organizational goals by providing more autonomous power to employees and subordinates.

In the field of computer science, authorization is the power granted by the information system to a certain entity to process, store, or transmit information, designated by the approving authority.

In the field of identity authentication, authorization refers to a mechanism that allows clients to access server resources to a limited extent after passing identity authentication.

Why do we need to carry out 'authorization'?

In the user system that has been established, when your API needs to determine whether the current accessing user can access the current resource, you need to build your own permission system. Authorization is a very important concept in the permission system, referring to the process of determining which permissions a user has, which is completely different from authentication.

For enterprises, authorization can clarify the relationships between organizational members, making responsibilities and boundaries clearer, convenient for company management; at the same time, authorization can ensure data security, prevent risks, and different permissions allow different operations, which can prevent accidents such as user deliberate damage, data leakage, and误操作; authorization can improve the efficiency of decision-making, and excellent authorization and permission management make the system more operable, improving employee work efficiency.

From the perspective of products, authorization can ensure the security of product system use and data, prevent illegal operations and data leakage; authorization can also improve the operability of the system and enhance user experience; in addition, good authorization functions can enhance product value, making it more competitive in the market.

Authorization modes

The main authorization modes are two, namely, the authorization code mode based on the OAuth 2.0 process, and the centralized verification of user authorization through API interfaces to the authorization center.

Authorization modes based on the OAuth 2.0 framework

OAuth2 framework is a secure, lightweight, and standardized authorization system designed to facilitate the authorization process among resource providers, callers, and resource owners. If the authorization process does not involve the resource owner, the client_credentials mode can be used. This mode is generally used for the M2M mode of backend servers. You can obtain the application ID and key on the application details page, and you need to store them securely on your server.

You can use the OAuth2.0 client_credentials to simulate issuing an access_token with specific scope permissions:

curl --request POST \ --url https://${YOUR_AUTHING_DOMAIN}/oidc/token \ --header 'accept: application/json' \ --header 'cache-control: no-cache' \ --header 'content-type: application/x-www-form-urlencoded' \ --data 'grant_type=client_credentials&scope=customScope&client_id=CLIENT_ID&client_secret=CLIENT_SECRET'

Authing will dynamically decide which permissions the AccessToken should have based on the requested resources and context by the caller, and return the rejected scope:

{"access_token": "...", "token_type": "Bearer", "expires_in": 3599, "scope": "user", "scope_rejected": "xxx yyy"}

The scope is the list of permissions that the access_token has, separated by spaces. You can judge which permissions the user has on the backend through the scope.

When the authorization process involves the participation of the resource owner, you can use the authorization code mode in the OAuth2.0 framework. You need to place the permission items in the scope parameter of the authorization link, for example:

https://${YOUR_AUTHING_DOMAIN}/oidc/auth?client_id={your application ID}&scope=openid book:read book:delete&redirect_uri={your business callback address}&state={random string}&response_type=code

The resource owner needs to click the link, after which the login page will appear. The resource holder authenticates their identity and authorizes the resource to the caller.

After completing the authentication and authorization, the browser will jump to the business callback address and pass the authorization code through the URL. The caller can use this authorization code to obtain an AccessToken with permissions from Authing, which is used to access the resources of the resource provider.

The code for exchanging Code for Token is as follows:

curl --request POST \ --url https://${YOUR_AUTHING_DOMAIN}/oidc/token \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data client_id={Application ID} \ --data client_secret= {Application Secret} \ --data grant_type=authorization_code \ --data redirect_uri={Callback URL} \ --data code={Authorization Code}

Similarly, Authing will dynamically decide which permissions to issue in the AccessToken based on the requested resources and the context of the caller's request, and return the rejected scope:

{ "access_token": "...", "token_type": "Bearer", "expires_in": 3599, "scope": "openid book:read", "scope_rejected": "book:delete" }

Of course, the resource provider must verify whether the caller carries an AccessToken with the necessary permissions before returning the resource. Once all checks are passed, the resource can be returned safely.

Using Access Control API

In addition to using the OAuth2.0 client_credentials mode, general-purpose access control APIs can also be used. These APIs allow for the creation of roles, authorization of roles to roles, and determination of whether a user has a certain permission. We support SDKs for languages such as Node.js, Python, Java, PHP, and C#. For more details, please seeDocument.

Access Control Model

Currently, Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) are two widely adopted access control models, each with its own advantages and disadvantages.

The RBAC model is simpler to build, but the drawback is that it cannot achieve fine-grained authorization of resources (it authorizes a category of resources rather than a specific resource); the ABAC model is relatively complex to build and has a higher learning cost, but its advantage lies in fine granularity and dynamic execution based on context.

Role-based access control (RBAC)

What is RBAC?

Role-based access control (RBAC), abbreviated as RBAC, refers to granting related permissions to users through their roles (Role), which realizes fine-grained access control and provides a simpler and more controllable management method compared to directly granting permissions to individual users.

When using RBAC, by analyzing the actual situation of system users, based on common responsibilities and needs, they are assigned to different roles. Then, each user can be granted one or more roles, each role having one or more permissions. This user-role, role-permission relationship allows us to no longer manage individual users separately; users inherit the required permissions from the roles they possess, making user authorization simpler.

Use cases of RBAC

Taking a simple scenario as an example (Gitlab's permission system), the user system has three roles: Admin, Maintainer, and Operator. These three roles have different permissions, for example, only Admin has the permissions to create and delete code repositories, while other roles do not.

By granting a user the 'Admin' role, they gain the permissions to 'create code repositories' and 'delete code repositories'.

Not directly granting users authorization policies is to consider the extensibility later. For example, if multiple users have the same permissions, they need to be specified individually when allocated, and the permissions of these users also need to be modified one by one when changes are made. With roles, we only need to define the permissions for the role, and then assign users with the same permissions to the same role, which is convenient for permission management.

Attribute-Based Access Control (ABAC)

What is ABAC?

Attribute-Based Access Control (ABAC) is a flexible authorization model that controls whether there is permission to operate on an object through one or more attributes.

Among them, A in ABAC, which stands for attribute (Attribute), is used to represent the characteristics of subject, object, or environmental features. Attributes are stored in the form of key-value to store this information, for example, my role in the company is developer, where 'role' is the key and 'developer' is the value.

ABAC attributes are generally divided into four categories: user attributes (such as age), environmental attributes (such as current time), operational attributes (such as read), and object attributes (such as an article, also known as resource attributes), so theoretically, it can realize very flexible permission control.

Use cases of ABAC

For example, employees of the company in Beijing will attend a training meeting using the company's internal network tomorrow. 'Beijing' and 'company internal network' are environmental attributes, and 'attending a training meeting' is an operational attribute. When it is necessary to dynamically calculate permissions based on these attributes, the RBAC authorization model will not meet the needs. In this case, the ABAC authorization model needs to be used.

Under the ABAC permission model, you can easily implement the following permission control logic:

1. Authorize a specific editor to edit a specific book;

2. When the department of a document is the same as the user's department, the user can access this document;

3. When a user is the owner of a document and the status of the document is draft, the user can edit this document;

4. Prohibit members of Department A from accessing System B before 9:00 in the morning;

5. Prohibit access to System A as an administrator in places other than Shanghai;

There are several common points in the above logic:

1. Specific to a particular resource rather than a category of resources;

2. Specific to a particular operation;

3. Strategies can be dynamically executed based on the context of the request (such as time, geographic location, resource tags);

If summarized in one sentence, you can grant specific permissions to a resource under specific circumstances with fine-grained authorization.

The RBAC authorization model is based on role-based access control. When facing large enterprises and organizations, the RBAC authorization model requires maintaining a large number of roles and authorization relationships, while the ABAC authorization model is more flexible. In addition, when resources are continuously increasing, the RBAC authorization model needs to maintain all related roles, whereas the ABAC authorization model only needs to maintain according to relevant attributes, making it more scalable.

Implementing permission models with Authing

In Authing's permission system, we simultaneously support the RBAC and ABAC permission models, which strike a balance between management efficiency and authorization granularity. In the permission management module of the Authing console, resources and roles can be managed uniformly, and personalized authorization rules can be used to grant operational permissions of resources to roles or specific users.

When granting authorization, the first step is to select the principal of the authorized user. In addition to authorizing users and roles, authorization can also be given to groups and specific organizational nodes. This multi-dimensional authorization model can greatly facilitate authorization management.

We can define authorization rules for each authorization - allowing or denying access to a resource under certain conditions.

After defining the authorized resources in the console, you can integrate the permission model defined in Authing into your own project through the API form, and control the resource permissions.

Firstly, initialize the Management SDK:

Here we take the Node SDK as an example, and we also support SDKs for Python, Java, C#, PHP, and other languages. For details, please see https://docs.authing.cn/

import { ManagementClient } from 'authing-js-sdk'; const managementClient = new ManagementClient({ userPoolId: "YOUR_USERPOOL_ID", secret: "YOUR_USERPOOL_SECRET" });

The three parameters of calling the managementClient.acl.isAllowed method are:

• userId: User ID, the user can be directly authorized to perform operations on specific resources, or inherit the permissions authorized by roles.

• resource: Resource identifier, such as repository:123 indicates the code repository with ID 123, repository:* indicates the category of code repositories as resources.

• action: Specific operation, such as repository:Delete indicates the operation of deleting the code repository.

const { totalCount, list } = await managementClient.acl.isAllowed("USER_ID", "repository:123", "repository:Delete");

The Authing policy engine will dynamically execute the policy according to the permission strategy you configure, and finally return true or false. You can simply judge whether the user has the operation permission based on the returned value.

Summary

Authing not only implements role permission inheritance in the RBAC model through user and role objects, but also realizes a more fine-grained and dynamic ABAC permission model on top of it. This is a gradual process, and as the complexity of the business continues to increase, you can quickly build a permission model suitable for your business scenario based on Authing's powerful and flexible permission system.