HENGSHI SENSE Data Permission Solution

Introduction

Purpose

This document primarily describes the data permission solution for HENGSHI SENSE, which involves synchronizing internal personnel attributes and organizational structure information within the enterprise to enable each user within the enterprise to have read permissions for business data within the HENGSHI SENSE system.

The intended audience for this document includes: HENGSHI SENSE designers and developers, enterprise customer developers of HENGSHI SENSE.

Background

To meet the requirement of filtering data based on data permissions from the business system.

Glossary

No.	Term	Explanation
1	Permission	The scope of authority a user has over resources
2	Functional Permission	The operational permissions a user has within the HENGSHI SENSE system
3	Data Permission	The dataset upon which data is calculated when a user views each report in the HENGSHI SENSE system
4	User Attribute	Custom information part of the user (user attribute/profile, used for filtering user groups, filtering data), usually synchronized by the enterprise customer to HENGSHI SENSE, see Synchronization Interface for details
5	Organizational Structure	Internal organizational structure information of the enterprise, typically a tree structure, with each user belonging to one or multiple nodes

Overview

Data Permission Rules

= Authorized User Group + Data Filter

Specifying Authorized User Groups

• By specifying specific users
• By specifying specific groups
• By specifying user-defined attributes

Generating Data Filters

• Specifying constant filters in the filter
• Using user-defined attributes in the filter, for example:
  • table1.region = $USER.region
  • table1.years_of_service <= yeardiff($USER.hire_date, now())

Data Permission Rules Based on Organizational Structure

1. The business data table contains fields related to organizational structure, such as department ID.
2. The user-defined attributes include organizational structure-related attributes, such as department ID.

Objects of Data Permission Control

• Tables in data connections
• Datasets in published applications

Process Design

Process Design Principles:

• Reduce coupling between systems
• Avoid repetitive operations
• Use results only, avoid copying implementation logic, and prevent one party's logic modification from requiring the other party to synchronize modifications

Process:

Process Explanation:

• Synchronize Attributes: During API calls/user logins, the SSO server passes the permissions the user has, such as department ID sets, organization ID sets, or inaccessible ID sets. The specific data passed is not restricted and is determined by the SSO server based on business needs. Hengshi saves these attributes passed by the SSO server into the user's attributes.
• Declare Attributes: Declare user attributes in the system, refer to User Attribute Declaration
• Use Attributes: Set up in [Data Connection]->[Select Data Table]->[Permission Control], specify the organization ID or department ID fields in the table, and match them with the permission attributes in the user attributes for filtering.

Example 1:

• User U logs in and synchronizes the user attribute org_id_set (with the value being the ID set of C and CC1, CC2), org_id_set=["C","CC1,"CC2"].
• Declare the user attribute org_id_set in the system.
• Table A contains companies C, CC1, CC2, and companies D, E. Set the permission filter for table A to org_id in the user attribute org_id_set (table A.org_id in $USER.org_id_set)

Therefore, based on the permission filter, user U can only see data from C, CC1, and CC2.

Data Structure

User Attributes

Basic Information Section

User Attributes, where the config field represents the JSON object of user attributes.

Synchronization Interface

API

Synchronize user attributes via API calls, refer to User Attributes

Synchronization During SSO Login Authentication

1. During login, user attributes are passed through the SSO server. Fields that are not mapped will be automatically saved as user attributes. For example, if the SSO server passes three fields: loginName, email, and position, and only loginName and email are mapped to the user's loginName and email, respectively, the position field will be saved as a user attribute. This logic applies to all authentication methods except username and password authentication.
2. The mapping relationship is configured on the authentication method page. Refer to Mapping Meaning and Instructions. An example using OAuth is provided below:

Example: OAuth Login Passing User Attributes

OAuth Server Response:

{
  "login_name":"zhangsan", // Username mapping
  "name":"zhangsan", // Display name mapping
  "email":"zhangsan@hengshi.com", // Email mapping
  "roles":[ // Role mapping
    "system admin",
    "data admin"
  ],
  "auths": [1,2,3],
  "leaderId": 1,
  "position": "manager"
}

Fields that are not mapped, such as auths, leaderId, and position, are automatically saved to user attributes. They can be used by following the steps in the Process Instructions.

Notes

1. There are numerous login authentication protocols. The example above is in JSON format. Other protocols, such as LDAP, SSO (CAS, SAML, etc.), or third-party authorization (DingTalk, WeChat Work, Lark, etc.), will save unmapped field information as user attributes based on the attributes passed by the protocol.
2. For protocols that do not allow flexible or customizable user attribute passing, synchronization can be done using the API.