Meaning of Authorization

In the general realm, empowerment is the process by which leaders achieve organizational goals by providing more autonomy to employees and subordinates.

In computing, authorization is the authorisation of an entity to process, store, or transmit information by the information system’s designated approving authority.

In the field of identity authentication, authorization refers to a mechanism by which clients can access server resources only after being authenticated.

Why “license”?

In an already built user system, when your API needs to determine whether the currently accessing user can access the current resource, you need to build your own permissions system. Authorization is a very important concept in the permission system. It refers to the process of judging what permissions users have, which is completely different from authentication.

For enterprises, authorization can clarify the relationship between members of the organization, make responsibilities and boundaries clearer, and facilitate the management of the company. At the same time, authorization can ensure data security, risk prevention and control, different permissions allow different operations, can prevent user damage, data leakage, misoperation and other accidents; Authorization can improve the efficiency of decision-making. Excellent authorization and authority management make the system easier to operate and improve the work efficiency of employees.

From the product perspective, authorization can ensure the use of product system security and data security, prevent illegal operations and data leakage; Authorization can also improve system operability and user experience. In addition, good licensing features will increase the value of the product and make it more competitive in the market.

Authorization model

There are two authorization modes: authorization code mode based on OAuth 2.0 process and centralized authentication of user authorization through API interface to authorization center.

Authorization mode based on OAuth 2.0 framework

The OAuth2 framework is a secure, lightweight, standard authorization system designed to help complete the authorization process between resource, caller, and resource owner. If the resource owner is not involved in the authorization process, the client_credentials mode can be used. This mode is typically used in M2M mode for back-end servers. You can get the app ID and key from the app details page, which you need to store securely on your server.

You can simulate issuing access_tokens with specific scope permissions using OAuth2.0’s client_credentials:

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'
Copy the code

Authing dynamically decides which privileges to issue AccessToken based on the resource and context requested by the caller. And return the rejected scope:

{
  "access_token": "..."."token_type": "Bearer"."expires_in": 3599."scope": "user"."scope_rejected": "xxx yyy"
}
Copy the code

Scope is the list of permissions that the access_token has, separated by Spaces. You can use scope at the back end to determine what permissions the user has.

When the authorization process involves the participation of the resource owner in authorization, the authorization code pattern in the OAuth2.0 framework can be used. You need to place the permission item in the scope parameter of the link that initiates the authorization, for example:

https://${YOUR_AUTHING_DOMAIN}/oidc/auth? Client_id ={your app ID}&scope= OpenID Book: Read Book :delete&redirect _URI ={your business callback address}&state={random string}&response_type=code
Copy the code

You need to get the resource owner to click on the link, which leads to the login page, where the resource owner authenticates himself and authorizes the resource to the caller.

After the authentication and authorization is complete, the browser redirects to the service callback address and transmits the code authorization code through the URL. The caller can use this code authorization code to access Authing with access to AccessToken, which is used to obtain resources from the source party.

Code The Code for exchanging tokens 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 key} \ --data grant_type=authorization_code \ --data Redirect_uri ={callback address} \ --data code={authorization code}Copy the code

Similarly, Authing dynamically decides which privileges to issue AccessToken based on the resource and context requested by the caller. And return the rejected scope:

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

Of course, the resource side must verify whether the caller carries the AccessToken with the permission before returning the resource. When all the checks are passed, the resource can be safely returned.

Access Rights API

In addition to the client_credentials mode of OAuth2.0, you can also use the generic permissions API to create roles, authorize roles to roles, determine whether a user has permissions, and so on. We support the SDK for node.js, Python, Java, PHP, C# and other languages. Please refer to the documentation for details.

The permissions model

At present, role-based access control (RBAC) and attribute-based access control (ABAC) are two widely used permission models, each of which has its own advantages and disadvantages.

The RBAC model is simpler to build, but has the disadvantage of not being able to authorize resources in a fine-grained manner (all resources are authorized to a certain class rather than a specific resource). ABAC model construction is relatively complex, high learning cost, the advantages of fine granularity and dynamic execution according to context.

Role-based Access Control (RBAC)

What is RBAC?

Role-based Access Control (RBAC) refers to granting permissions to users based on their roles. It implements fine-grained access control and provides a simpler and controllable management mode than granting permissions to a single user directly.

When RBAC is used, system users are assigned to different roles based on common responsibilities and requirements by analyzing their actual situation. Then can be granted to each user one or more roles, each role has one or more privileges, the relationship between user roles, role permission, that we can no longer separate single user management, the role of the user from inside inherit the required permissions, so as to make the user empowerment it more simple.

Usage scenarios of RBAC

In a simple scenario (Gitlab permission system), the user system has Admin, Maintainer, and Operator roles. These roles have different permissions. For example, only Admin has permissions to create and delete code repositories.

We grant a user the role of “Admin” and he has the “create repository” and “delete repository” permissions.

For future scalability, users are not directly authorized with policies. For example, if multiple users have the same permission, you need to assign the same permission to each user and modify the permission for each user. After a role is created, you only need to set permissions for the role and assign users with the same permissions to the same role, facilitating rights management.

Attribute Based Access Control (ABAC)

What is ABAC?

Attribute-based Access Control (ABAC) is a flexible authorization model, which controls the Access to objects through one or a group of attributes.

Among them, A in ABAC, also known as Attribute, is used to represent the characteristics of subject, object or environment features. Attribute uses the form of key-value to store such information. For example, my role in the company is developer. Role is the key, developer is the value.

ABAC attributes are generally divided into four categories: user attributes (such as user age), environment attributes (such as the current time), operation attributes (such as read) and object attributes (such as an article, also known as resource attributes), so it is theoretically possible to achieve very flexible permission control.

Usage scenarios of ABAC

For example, the employees of the company in Beijing will use the company Intranet to attend the conference training tomorrow. Beijing and Intranet are environment attributes, and Attending meetings and training are operation attributes. When you need to dynamically calculate permissions based on these attributes, the RBAC authorization model will not suffice. This is where the ABAC authorization model is needed.

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

Authorizing an editor to edit a specific book;
When the department of a document is the same as the user’s department, the user can access the document.
When the user is the owner of a document and the status of the document is draft, the user can edit the document.
Block access to System B from Department A until 9:00 a.m.
Access to system A as an administrator is prohibited in places other than Shanghai;

There are several commonalities in the above logic:

Specific to one resource rather than one type of resource;
Specific to an operation;
Dynamic execution of policies based on the context of the request (such as time, location, resource Tag);

If boiled down to a single sentence, you can fine-grained grant specific permissions to a resource under what circumstances.

The RBAC authorization model is role-based access control. When facing large enterprises and organizations, the RBAC authorization model needs to maintain a large number of roles and authorization relationships, while the ABAC authorization model is more flexible. In addition, when resources are increasing, the RBAC authorization model needs to maintain all relevant roles, while the ABAC authorization model only needs to maintain related attributes, which is more extensible.

Implement the permission model with Authing

In Authing’s permission system, we support both THE RBAC and ABAC permission models, which combine efficiency of administration with granularity of authorization. In the permission management module of the Authing console, you can manage resources and roles in a unified manner, and authorize the operation rights of resources to roles or users by using personalized authorization rules.

During authorization, the principal of the authorized user is selected first. In addition to users and roles, groups and organizational nodes can be authorized. This authorization model of different dimensions brings great convenience to authorization management.

For each authorization, we can define authorization rules that allow or deny access to a resource under certain conditions.

Once authorized resources are defined in the console, you can integrate the permissions model defined in Authing into your own projects via apis to control resource permissions.

Initialize the Management SDK first:

Here we take the Node SDK as an example. We also support the SDK of Python, Java, C#, PHP and other languages. Please refer to docs.authing.cn/ for details

import { ManagementClient } from 'authing-js-sdk';

const managementClient = new ManagementClient({
    userPoolId: "YOUR_USERPOOL_ID".secret: "YOUR_USERPOOL_SECRET"
});
Copy the code

Call managementClient. Acl. IsAllowed method, three parameters are:

UserId: indicates the userId. A user can be directly authorized to perform operations on specific resources or inherit the permissions granted to roles.
Resource: indicates a resource identifier. For example, repository:123 indicates a code repository whose ID is 123. Repository :* indicates a code repository.
Action: indicates a specific operation, such as repository:Delete indicates the operation to Delete the code repository.


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

The Authing policy engine will dynamically execute the policy based on the configured permission policy and return true or false. You can determine whether the user has the operation permission based on the return value.

conclusion

Authing not only implements RBAC model role permissions inheritance through both user and role objects, but also implements a more fine-grained and dynamic ABAC permissions model on top of this. This is a gradual process, and as the complexity of your business increases, you can quickly build a permissions model that suits your business scenario based on Authing’s powerful and flexible permissions system.

Fast implementation of fine-grained identity rights management