Application User Permissions are used to control the knowledge scope accessible to end users within a certain application. With this capacity, you can configure different accessible knowledge bases for different users under the same application, set knowledge isolation rules by department, position, or customer type. After publishing the application, it supports isolating knowledge base permissions accessible to different users through application APIs.
How to Use Application User Permissions
The product provides two methods, role-based access control and external privilege system control, based on the difficulty level of actual scenarios. A single application only supports choosing one of them when using the application user permissions feature, and allows switching methods.
Interpretation of Terms
To make it easy for follow-up case-sensitive identification, description:
Application User
Refers to users who consult through dialogue entry (web page, built-in page, business system, etc.) based on application API, such as in-house employees or external customers.
Knowledge scope
Refers to the retrievable knowledge collection in an application, usually consisting of one or more knowledge bases, document collections, or Tags.
Platform permissions
Control who can access the login platform, configure applications, and manage the knowledge base.
Application User Permission
Control which knowledge base / knowledge scope terminal users can query when using a certain application.
Feature Entries
After adding knowledge to the knowledge base, users on the application side can by default access all knowledge under the application. User permission configuration on the application side takes effect at the application dimension: each application is configured separately and does not affect each other.
Configuration entry path: In the target application, enter App Settings > Advanced Setting > Application Side User Permission to perform enablement and approach selection.
Note:
To underwrite user permission on the application side takes effect, please first complete the application configuration and save and publish, then configure user permission and API request permission.
Provide two configuration methods. A single application supports only one method at the same time and allows switching anytime.
1. Role-based access control (in page settings)
Manage users and roles within the platform, and configure accessible knowledge scope for roles.
2. Permission control by external permission system (API case-sensitive)
Integrate with external privilege system, and the external system returns current user access permission for each knowledge slice.
Option 1: Role-Based Access Control
Through User Management and Role Management, control application user permissions within the platform. The approach is: create a role, configure the accessible knowledge scope for the role, then bind the application user to the role. When a user asks a question, the system searches within the knowledge scope set for the role.
1.1 User Management
Maintain basic information for application side users and bind roles.
User ID
Technically used to correspond to visitor_biz_id in application API.
username
Nickname for user display, not mandatory to be unique.
Role permission
Select an existing role from Role Management. One user can bind multiple roles.
1.2 Role Management
For defining roles and their corresponding knowledge scope collection. A role with access to all knowledge scopes is provided by default. Support creating new roles and selecting knowledge search scopes for them, such as:
Product Department role: Only check the product relevant knowledge base or tag.
Finance role: Only check the finance relevant knowledge base.
Example interface:
Note:
When a user binds multiple roles, the user's actual knowledge permission is the union of these roles' knowledge scopes.
1.3 Bind User and Role
Add user ID and username in user management, and select a role for the user. When the user makes an inquiry on the application, reply based on the knowledge scope of the role permission.
User ID: Under one application, user ID cannot be repeated and only supports filling in letters, digits and characters.
username: Represents the user nickname, without judging repetition.
Role permission: Select Add Role in role management. One user can add multiple roles.
1.4 Import User ID in Application API
Application side connects to Application API and needs to import user ID in request, so the system can identify current consultation user and apply corresponding permissions.
In request parameters, import user ID via visitor_biz_id. For example:
For example, when Xiao Zhang consults, input the following request parameters:
"visitor_biz_id": "234",
When Xiao Wang consults, input the following request parameters:
"visitor_biz_id": "123",
Option 2: Control Privileges by External Privilege System
When a business has a mature privilege system (such as unified user permission service, OA permission center), the solution can be used to integrate with external systems, allowing the external system to determine application side user access permission to knowledge.
Note:
Compared with solution 1, this solution authorizes the external system to maintain the user-to-knowledge mapping, and the platform is only responsible for calling and executing filtering during the retrieve stage.
2.1 How It Works
After enabling the external privilege system, the retrieve process within application is roughly as follows:
1. The application side user calls the application API to ask, include user identity in the request (such as visitor_biz_id).
2. The application retrieves a batch of candidate knowledge slices from the knowledge base (permission filtering not carried out).
3. The platform initiates call externally, include in request:
Current user information (such as user ID, department information, per integration agreement).
Currently recalled knowledge slice list (such as slice ID, associated knowledge base, and identification information).
4. The external privilege system judges whether the user has access permission for each slice based on in-house permission rules, and returns the authorized slice collection or authorization result.
5. The platform filters out unauthorized slices based on the returned results and only sends the authorized part to the large model to generate answer.
2.2 Integration Instruction
This capacity requires integration with the external privilege system through the API. The specific interface protocol (request parameter, returned field, authentication method) must be agreed and configured with the platform provider.
Must-Knows
User permission on the application side takes effect at the application dimension, and configuration of different applications is independent of each other.
When using usage scheme 1 (role-based access control), please ensure:
The user ID is unique within the app and matches the visitor_biz_id.
User and role, role and knowledge scope configuration keep synchronized.
Switchover solution (from role-based mode to external privilege system, or reverse switchover):
After toggling, the new solution becomes the unique permission control method that takes effect.
It is advisable to perform during off-peak hours and complete the new scheme configuration and verification in advance.
