Authing DocsDocuments
Concept
workflow
Guides
Development Integration
Application integration
Concept
workflow
Guides
Development Integration
Application integration
Old Version
Guides
  • Quick start

  • Authenticate the user

  • Authority management for users

    • Choose the appropriate permission model
    • Integrate RBAC permission model into your application system
    • Integrate ABAC permission model into your application system
    • Use permission group management permission resources
    • Manage resource permissions
  • Authorization

  • Manage user accounts

  • Manage User Directory

  • Management Application

  • Become a source of federal authentication identity

  • Connect to an external identity provider (IdP)

  • Open up WeChat ecology
  • Migrate users to Authing

  • Management organization

  • Expandable capabilities

  • Audit Log

  • Configure security information

  • Configure user pool information

  • Deployment plan

  • Frequently Asked Questions FAQs

  1. Guides
  2. /
  3. Authority management for users
  4. /
  5. Integrate ABAC permission model into your application system

¶ Integrate ABAC permission model into your application system

Update Time: 2025-05-14 08:32:28
Edit

Earlier we introduced what is attribute-based access control (ABAC), and then this document introduces how to quickly integrate the ABAC permission model into your system based on Authing. In the last section, we introduced how to integrate the RBAC permission model. I believe you have realized that the RBAC permission model is static, which means there is no dynamic attributes such as environment and object properties involved. So it is difficult to achieve scenarios of the following Access control:

  • When the department of a document is the same as the department of the user, 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;
  • Persons from Department A are prohibited from accessing System B before nine o'clock in the morning;
  • It is forbidden to access system A as an administrator in places other than NewYork;

¶ The Main Component of ABAC

In ABAC, whether an operation is allowed is determined based on the dynamic calculation of the object, resource, operation and environment information.

  • Object: The object is the user who is currently requesting access to the resource. User attributes include ID, personal resources, roles, department and organization memberships, etc.;
  • Resources: Resources are assets or objects (such as files, data, servers, and even APIs) that the current user wants to access. Resource attributes include file creation date, file owner, file name and type, data sensitivity, etc.;
  • Operation: The operation is the operation that the user tries to perform on the resource. Common operations include "read", "write", "edit", "copy" and "delete";
  • Environment: The environment is the context of each access request. Environmental attributes include the time and location of the access attempt, the object's device, communication protocol and encryption strength, etc.

¶ How ABAC make decision

During the execution of ABAC's decision statement, the decision engine will dynamically calculate the decision result based on the defined decision statement, combined with attributes such as objects, resources, operations, and environment.

Whenever an access request occurs, the ABAC decision-making system will analyze whether the attribute value matches the established policy. If there is a matching policy, the access request will be allowed.

For example, the policy "When a document belongs to the same department as the user's department, the user can access this document" will be matched by the following attributes:

  • The department of the object (user) = the department of the resource;
  • Resource = "document";
  • Operation = "Access";

The policy "Prohibit people in department A from accessing system B before nine o'clock in the morning;" will be matched by the following attributes:

  • Object's department = A department;
  • Resource = "B System";
  • Operation = "Access";
  • Environment = "The time is 9 AM".

¶ Specify restrictions when authorizing resources in Authing

When we authorize resources, we can specify restrictions. For example, in the following example, we have added a restriction: the current requesting user is required to pass MFA authentication.

In addition to the MFA authentication attribute, you can also obtain the following attributes in the context of Authing's policy engine:

  • User object attributes: such as gender, organization, group, role, whether the email is verified, whether the phone number is verified, user defined data, whether the user has passed MFA authentication, the user's last MFA authentication time, etc.
  • Environmental attributes: client IP, client UA, client browser, request source country, request source state/province, request source city, etc.;
  • Resource attributes: resource creation time, resource owner, resource tag, etc.;

You can compose flexible policy authorization statements based on these attributes.

Prev: Integrate RBAC permission model into your application system Next: Use permission group management permission resources
  • The Main Component of ABAC
  • How ABAC make decision
  • Specify restrictions when authorizing resources in Authing

User identity management

Integrated third-party login
Mobile phone number flash check (opens new window)
Universal login form component
Custom authentication process

Enterprise internal management

Single Sign On
Multi-factor Authentication
Authority Management

Developers

Development Document
Framework Integration
Blog (opens new window)
GitHub (opens new window)
Community User Center (opens new window)

Company

400 888 2106
sales@authing.cn
16 / F, Block B, NORTH STAR CENTURY CENTER, Beijing(Total)
room 406, 4th floor, zone B, building 1, No. 200, Tianfu Fifth Street, Chengdu(branch)

Beijing ICP No.19051205-1

© Beijing Steamory Technology Co.