The full text is 8000 words, and the expected reading time is 18 minutes

One, foreword

Baidu ToB Vertical Account Authority Platform (hereinafter referred to as the platform) is a basic platform dedicated to providing universal account authority services for all product lines of Baidu ToB vertical category, providing services covering tenant management, account management, single sign-on, authority control, account security and enterprise qualification. After hosting account and permission related services to the platform, the business side can focus on its own business research and development. At present, it has been connected to more than 10 million enterprise accounts of aipanfan, Aipurchasing, Xunkebao and Haiyi’s first-phase product lines, providing one-stop account and permission solutions for various ToB services. The business architecture diagram of the simplified version is as follows:

▽ Platform business architecture

Here is a list of necessary noun explanations to better understand the content of this article:

2. Account login service

2.1 Enterprise organization and account model

= = = = = = = = = = = = = = = = =

The platform supports a customer to register multiple tenants in multiple product lines, and the data among tenants is isolated from each other. By default, each tenant creates a master account with the maximum super administrator rights, and generates a tenant organization structure tree with jurisdiction. The master account can create multiple sub-accounts, and each account can be bound to multiple third-party accounts or the customer company’s own account system (such as wechat, mobile phone number, Apple account, UC, passport, etc.). The super administrator can assign different roles to each account and have different function permissions. For example, assign front-line roles to customer service personnel with IM communication rights.

Business organization and account model

2.2 Stable, efficient and configurable Unified Login Service

The business scenario of ToB vertical class not only needs to support Saas business, but also the private deployment business of big customers. In terms of the design goal, the account login service of the platform needs to provide a secure, stable, efficient and configurable unified login service for all kinds of business.

△ Logon service architecture Diagram

As a login service for enterprise applications, many security policies are added in the design of the process to ensure the security of enterprise users, so the overall login process is complicated:

First, take account password login as an example. When the user enters the page of Aipanpan, the system page is initialized, and a set of unique encryption information and duration is generated for the current page. The encrypted information is used for encryption during the transmission of information such as the user account and password. Duration is the duration of the current page. If the user stays still on the current page for longer than the specified period, the page information becomes invalid and the system reloads the page. When users fill in the information such as account number, password and verification code, a series of encrypted information transmitted to system, the system will be generated at the beginning of the page the encryption to encrypt the information find keys, and decryption, such as after completion of the basic account password information check passes through a series of security policies, such as login very land, the commonly used equipment inspection, mobile phone validation checks, etc. After the security policy passes, the system generates temporary authentication information and returns it to the front end. When the front end performs verification, the system replaces the temporary login information with the real one to complete a login.

△ Detailed flow chart of account and password

As a unified business basis for saas services, we need to solve several problems on login services:

  • How can login services be configurable? The configurable capability can support different enterprises to customize the login process according to their own business in the scenario of private deployment, and can also support the customization requirements of aipanfan saas service access to different product lines.

  • How to support multiple product line applications and single sign-on?

  • How to ensure account login security? The core of the login service is to ensure the security of the login function. As the first-level service of aipanpan, Aipurchasing and other systems, the security of the login process becomes very important to prevent the system from being maliciously invaded.

2.2.1 Configuring the Extension Capability

A complex problem is usually composed of several small problems, and dealing with a complex problem also involves many different processing steps. It is only necessary to divide the complex processing logic into different small steps in a divide-and-conquer way, so as to simplify the problem. Therefore, the core processing idea is to separate the different processing steps of the login process and map the steps to behaviors and operations. This gives you a number of different atomic behaviors, each of which corresponds to a different atomic operation.

2.2.1.1 Model abstraction

Based on this idea, a set of models can be abstracted, as shown in the figure below. Aifanfan account system can support access of multiple product lines, and one product line belongs to multiple accounts. P for product line, U for account, E for some atomic event of login service, C for login related configuration, and S for login related security policy. A product line can assemble atomic events required by different login processes, so the relationship between P and E is a one-to-many situation. Product line P can also have different configurations, such as login duration, whether to support multi-terminal simultaneous login, and the number of login terminals. No matter product line or account, there are a series of security policies, of course, these security policies can be the account granularity or product line granularity, such as the blocking policy for some black production accounts, accounts with abnormal login behavior, prompt policy to determine whether the account is frequently logged in, and so on.

△ Configuring scalability Figure 1

By splitting the steps of the login process and organizing them by different product lines, you can meet some customized requirements of the enterprise. However, how to support configurable operations in different login methods? Login services need to support different login methods, such as encrypted mobile phone login, scanning code login, third-party login and other mainstream universal login methods. In the design of configurable processes, it is necessary to ensure the universality of design, and the login processes of different login methods can be applied into a set of models. Abstract model M represents the login mode, which is also composed of different events. Product line P can customize the login mode required by its own products, which is displayed through the front-end login component. Of course, in order to consider the security and other aspects of configuration, also set up a blacklist, white list. The blacklist can be based on account levels, abnormal IP addresses, mobile phone numbers, etc. Whitelists are often related to security policies, such as cross-domain requests and jump requests. The following figure shows an abstract model of logon service configuration scalability based on some of the considerations above.

△ Configuring scalability Figure 2

2.2.1.2 Unified Login Process

Extension based on the design of the configuration of the ability, can be the beginning of the account password login process abstraction into flow chart of the following can be configured to log in, the first use of generic decryption encryption processing service for the request parameters, and then all kinds of events and the corresponding atoms of event handlers are registered to the CPU, by the central processor assembly process, The CPU queries the sequence of event numbers in the database configuration through the product line and login mode, and then triggers the execution firing step by step.

△ Unified login flowchart

2.2.2 Single sign-on

2.2.2.1 Process Introduction

Single sign-on (SSO) is generally applied to multiple application systems. Users can log in to trusted application systems only once. For example, visit A.baidu.com. After login, visit B.baidu.com, http://a.aifanfan… Can be without login system, users only need to log in once, each system can perceive the user has logged in.

△ Single sign-on comparison diagram

Based on the above description of single sign-on, it can be realized that only one login authentication credential is recognized by different ends. Since HTTP is stateless, it is natural to think that cookies are used to transfer user information of different ends. However, cookies are strongly correlated with domain, and there are problems of loss based on browsers. There are two problems in using cookies in different interworking login states: one is cross-domain problem; Second, the problem of cookie loss. Platform based on CAS protocol design to achieve a set of multi-terminal single sign-on process, not only can solve the cookie problem based on the browser, but also support the login and communication between native applications.

The following figure is the main flow chart of platform account sso. When system A uses ToB account to log in, after successful login, the authentication center will generate A temporary authentication information Stoken, which will be written into the cookie Ptoken under the domain name www.b.com of the authentication center. When the system successfully switches to the system, the server gateway of service A integrates with the login verification SDK. The login verification SDK exchanges the temporary authentication information Stoken for the real and stable login state of system A and generates the login verification Atoken of system A only. When system A switches to system B, the server of system B checks the login status and finds no login information under the current domain name. The server performs 302 to switch to the authentication center, and the authentication center searches for the Ptoken in the cookie under the domain name www.b.com. After the authentication succeeds, A temporary Stoken will be returned to the request interface of system B, and the login verification SDK will exchange the temporary authentication information Stoken for the real and stable login state Btoken of system B. Therefore, when different systems authenticate information, they only need to care about the information stored in the domain name of the system. If login verification fails or cookies are lost, the system switches to the authentication center for verification again.

△ Single sign-on process

2.2.2.2 Authentication Logic

In the process introduction, we can know that there are three kinds of bills Stoken, Ptoken and Rtoken designed in single sign-on:

  • Stoken: service temporary token, issued by certification authority;

  • Ptoken: Stored on the server of the authentication center, the server requests to find the corresponding Ptoken based on the Key value of the Cookie or Header to obtain user information.

  • Rtoken: the token used by the service provider to verify the login status of the current system.

Generate Stoken

Temporary Stoken can be generated in two ways: one is generated when different systems jump to each other, and the other is generated when logging in. In either case, the authentication authority will issue the temporary Stoken. The data structure stored on the server side should contain the currently logged account information, verification information, client information, and encryption information. In terms of design, it is a Hash structure. Temporary Stoken stores all kinds of information and maintains key-value mode, so that reading and storage are clear and convenient. If the service system sets the address after login to a.baidu.con/index, after temporary Stoken is generated, the login service SDK appends Stoken to the address to a.baidu.con/index? St = xx… In order to ensure security, the validity period of temporary Stoken is set to 30 seconds. If the temporary token is not authenticated by the service request during 30 seconds, it is destroyed directly.

Stoken for Rtoken

When business A logs in and the business request is verified by the login SDK, it will get the Stoken on the request parameters. By decrypting the Key stored in the real storage, it will get the current login account information, verification information, client information and encryption information, and generate stable Rtoken. Copy the Stoken information to Rtoken and set the logon state time through the product line configuration. This step is temporary Stoken for real login state Rtoken.

Verify login state procedure

△ Schematic diagram of login state verification

2.2.3 Login Security Guarantee

2.2.3.1 Phased session control

Based on the introduction of the configurable login process and single sign-on (SSO) process, the server session is divided into three parts: login session, temporary session, and logon-state session. Session during the login period Controls the overall login process time to prevent malicious brushing. The session duration must be set to the minute level. If the session expires, the front-end login SDK needs to reload the initialization page information and restart the login process. Temporary sessions are designed for single sign-on (SSO), and the session duration is set in seconds. The real login session is the final login session of the user, and contains the real login Token information. The security of the login process is ensured through continuous exchange of the session. The following is the account and password login division diagram.

▽ Divided sessions by stages

2.2.3.2 Encryption and decryption of sensitive information

The encryption and decryption process is important in the login process. For security, the specific encryption algorithm is replaced. This uses symmetric encryption algorithm A, asymmetric algorithm B, account password encryption algorithm C, D and so on.

△ Encryption and decryption flow chart

The encryption and decryption process is as follows:

  1. First, A pair of secret keys are generated using encryption algorithm A, and the public key is used by the end. Random number Random on the end is encrypted together with public key algorithm A to send the current Random number to the login service.

  2. Random will decrypt it first, then generate a new key pair, store the private key and public key in session, and return the encrypted public key of algorithm B. The salt of the public key is the original Random parameter solved.

  3. Algorithm B on the end decrypts the real public key. Encrypt the password algorithm A.

  4. During password verification, the private key stored before will be retrieved from the session, the original password will be extracted, and then encrypted with algorithms C and D and compared with the database.

2.2.3.3 Other Security Measures

  • Cookie attribute

Secure: specifies whether cookies can be accessed only through HTTPS. Generally, cookies can be accessed using HTTP. If Secure is set to no value, cookies can be accessed only when HTTPS is used for connection.

HttpOnly: If the “HttpOnly” attribute is set in cookies, programs (JS scripts, Apple T, etc.) will not be able to read Cookie information, preventing XSS attacks.

Duration: Set the validity period. It is recommended that the validity period not be too large.

  • Request to check

Domain request restriction: Login-related interfaces support cross-domain scenarios. However, you need to verify the origin attribute of the request header and set a whitelist. Only the source origin configured by the login authentication center can be allowed. For some 302 jump requests, also set the whitelist control jump request.

Frequency: The frequency limit of login-related requests is set based on the current IP address, unique BROWSER ID, and client device ID. If the frequency limit exceeds the threshold, the frequency alarm is generated and the specified IP address, device, and account are blocked in time.

  • Verification code

Captchas are necessary, and the purpose of captchas is to distinguish between human and machine operations. The purpose of the verification code is to distinguish people from machines, prevent brute force cracking, and increase the difficulty of cracking passwords. It’s just that different stages show different forms, and the future trend is more intelligent and less perceptive, with better user experience. The login service supports image verification code, human-computer interaction sliding verification code, and mobile phone verification code. The service side can access different verification codes based on different security requirements.

2.3 ability to request

2.3.1 request to introduce

ToB multi-tenant account service supports relevant requirements of customers, and sometimes cooperates with external enterprises. It is necessary to ensure consistency of customer experience, get through the account authorization relationship between external platforms and account systems, and ensure that customers who log in to Aipanfan system can log in to external systems without having to. Therefore, it is necessary to form a complete authorization system. OAuth 2.0 is currently the most popular authorization mechanism used to authorize third-party applications and obtain user data. The owner of the data tells the system that it agrees to authorize third-party applications to access the data. The system then generates a short-term access token (token), which can be used in place of a password for third-party applications.

2.3.2 Authorization Process

After a user is authorized to log in to a third-party application connected to OAuth2.0, the third party can obtain the user’s interface call certificate (Access_token) and use the Access_token to call the OpenApi interface provided externally. Thus, it can obtain basic open information of aipanpan account users and help users to realize basic open functions. At present, the platform Oauth capability supports authorization_code mode, and the overall process of this mode is as follows:

  1. If the user does not log in to the account system, the user will be linked to the unified authorization login page by default. After the login, the user will pull up the application or be redirected to the third-party website with the code parameter of the authorization temporary ticket.

  2. Access_token is exchanged via API with code parameter plus AppID, AppSecret, etc.

  3. The access_token interface is invoked to obtain basic data resources or help users to perform basic operations.

Delta request sequence diagram

3. Permission service

As the basic permission service of ToB SAAS products, it serves multiple product lines, and needs to solve the complex and changeable demand for permission control for customers from all walks of life, providing the ability to control functional permission and data permission.

3.1 Problems and ideas

Problem 1: Each product line implements complex authority control logic in the code, resulting in high cost of understanding and maintenance of service authority.

Solution: Provide easy-to-access and extensible function authentication and data authentication capabilities;

Fault 2: Complex permission logic and high performance requirements make the system unstable as services develop and the number of customers increases.

Solution: To build high-performance and reliable authentication services;

3.2 Complex Function Authentication

3.2.1 Permission Access Mode

As shown in the following figure, the permission service includes login status verification and permission verification capability, and provides three authentication access modes:

① Authentication is realized through the unified gateway integration authentication SDK, including login state verification and permission verification;

② Without passing through the gateway, the authentication SDK is introduced to realize authentication;

3. Directly interact with permission platform through RPC interface to realize authentication;

_△___ Function authentication interaction diagram

Functional authentication consists of two parts, namely, the upgraded RBAC model, namely, TD-RBAC, and the equity package model, which are described in the following sections.

3.2.2 GD-RBAC Model (Dimension – and role-based access control model introduced by user group)

3.2.2.1 RBAC

Before introducing GD-RBAC, the basic RBAC model, Role Based Access Control, is introduced. The core of the role-based Access Control model is to introduce the concept of roles between users and permissions. Instead of directly associating users with rights, users are indirectly assigned rights by associating roles with users and rights with roles. In this way, users and rights are decoupled.

RBAC model is a new model developed in the 1990s. According to RBAC, the process of authorization can be abstractly summarized as follows: Whether Who can access What How and determine whether this logical expression is True is the process of solving, that is, transforming the permission problem into What and How, Who, What and How constitute the access permission triplet. In the RBAC model, there are three basic components: users, roles, and permissions. RBAC controls user permissions by defining role permissions and granting a role to a user. RBAC logically separates users from rights and greatly facilitates permission management.

  • User: Each User is identified by a unique UID and is assigned a different role.

  • Role: a virtual identity that is associated with a group of permissions and can be used only when it is associated with a user identity.

  • Resource: A Resource is an abstraction of the object entity with which a user interacts with the system.

  • Function: a service Function, usually composed of multiple interface addresses, such as opening a menu page and whether a button is visible.

  • Permissions (Auth) : Association mapping between roles and functions;

_ delta ___RBAC model

RBAC supports three well-known security principles: minimum authority, separation of responsibilities, and data abstraction

  • Minimum permission rule: RBAC can configure a role to the minimum set of privileges it needs to complete a task;

  • Principle of separation of responsibilities: You can invoke independent and mutually exclusive roles to jointly complete sensitive tasks.

  • Principle of data abstraction: this can be represented by abstraction of permissions;

3.2.2.2 GD – RBAC

The basic RBAC model is introduced above, but with the development of business, it cannot meet the complex authentication requirements of different product lines. For example, the same account needs to have different operation permissions under different clue pools in the transformation and promotion domain of Aipanfan. Based on this, we provide the GD-RBAC model:

The GD-RBAC model is upgraded on the basis of RBAC. The specific upgrade points are as follows:

1. Add a user group. Multiple users can be aggregated into a user group. Users in a user group have the same roles and have the same permissions, simplifying the user configuration process.

2. Add dimensions between user groups and roles. A user group can be associated with more than one dimension, and each dimension can be associated with a unique role, so as to achieve different permissions of the same user in different business scenarios.

_ delta ___GD – RBAC model

GD – RBAC example

With the GD-RBAC model, we can easily implement the user’s permission configuration in different cue pools, as shown in the figure below:

The same account can be associated with different dimensions (cue pools), and each cue pool can be associated with different roles, helping services to implement complex customized authentication.

The application of _△ ___Gd-RBAC model in cue pool business

3.2.3 Equity package model

Does gD-RBAC enable all function permissions? The following problems remain:

(1) Version differences: There are multiple sales versions of Aipanfan, such as Clue Manager Basic Version, Tuoke Standard version, Tuoke Professional version and private deployment version. The scope of permissions between versions is inconsistent, so the same super administrator role of different tenants under GD-RBAC must have different permissions. For example, the basic version of the administrator role does not have the standard version of the administrator’s unregistered guest subscription rights;

(2) Function purchase: for the same user with the same version, the user can purchase the product separately to achieve function purchase. At this time, even if there is no upgraded version, the permission has also been expanded;

In order to solve the above problems, we designed the equity package model to define the permissions set, as shown below:

_△___ Equity package model

The entitlement package is a customizable service attribute. Tenants can associate multiple entitlement packages. For example, the product line of Aipanfan has tenant version entitlement package, 400 phone function entitlement package, and user seat license entitlement package. The maximum set of tenant rights can be achieved through tenant associated equity packages. The three problems mentioned above can be solved flexibly and simply through the equity package model:

(1) The tenant version entitlement package solves the version differences: for example, the tenant version entitlement package can define the maximum function set of different versions, and users can have all the rights of the entitlement package if they buy different versions.

(2) Functional rights and interests package to solve the problem of additional purchase of functions: different product functions are packaged into separate functional rights and interests, and users can upgrade their rights by purchasing functions.

3.2.4 Functional authentication: GD-RBAC model + equity package model

Above, we have introduced gD-RBAC implementation to associate different permissions through roles, and to associate maximum permissions through equity packages, so the final permissions of users are equal to the intersection of the two permissions, as shown below:

_△___ Complete function authentication

3.2.5 Quick Application: Customer service operations

Based on gD-RBAC and equity package model, the platform can quickly support various permission usage scenarios of the business. Here are examples of customer service agent operation scenarios:

Let’s start with the concept of next-gen operations: one group of users can access and manipulate resources owned by another group of users. Typical example: A customer service employee with jurisdiction accesses the customer’s Ifan system using the customer service account and helps the customer complete system configuration.

If customer A needs to use their own account to access The system of Zhang SAN, it can set the organizational structure tree to have jurisdiction and join the user group of Zhang SAN, and then it can realize the login state of customer service and have the operation rights of customer Zhang SAN.

_△___ Quickly support customer service operations through the model

3.3 Flexible and Extended Data Authentication

In addition to the above functional authentication, different product lines have flexible data authentication requirements, for example, how to achieve data authority isolation or jurisdiction for accounts of different departments and positions? How to build customizable data authentication capabilities? We define user characteristics, which can be divided into general characteristics and custom characteristics:

General dimensional characteristics such as dimension, product line, industry and so on are available to every ToB product. We realize the general characteristics through dimensions, such as different dimensions for each department and position. The dimension model can be used to standardize user data, support feature cascade and build user feature network, so as to support customized user feature models for different services.

User-defined features are key value pairs stored in K-V format and used to flexibly define service data, such as customer source and address.

_△___ Data permission abstraction

_△___ Data dimension model

We store the dimension through the left and right value tree structure, so that the dimension has a certain hierarchical relationship. If the data is bound to the dimension node, there is a hierarchical relationship between resources, which is suitable for solving some hierarchical permission problems. For example, business administrators can define organizational structure and position to establish organizational structure tree and position tree respectively, as shown in the figure below:

_△___ Application example of left and right value tree in organization structure and position

So why use left and right value trees to store dimensions? Here is the basic principle of left and right value trees:

Each node is marked with left and right ordinals, where the lvalue of the root node is the minimum ordinal number of the tree, and the rvalue of the root node is the maximum ordinal number of the tree, and the height is 0.

  1. Query all descendants of a node: For any node, the lvalue of its descendants must be greater than the lvalue of the current node, and the rvalue of its descendants must be smaller than the rvalue of the current node

  2. Query the ancestor of a node: For any node, the ancestor’s lvalue must be smaller than the lvalue of the current node, and the ancestor’s rvalue must be larger than the current node

  3. Calculate the number of child nodes under a node: including itself: (rvalue – lvalue + 1) / 2; Excluding itself :(rvalue – lvalue – 1) / 2

  4. Node sort: Sort by leaf nodes.

In the figure below, dimension 1-organizational structure is marked by left-right value tree, where LV represents the height of the tree, Lleft represents the serial number on the left, and lright represents the serial number on the right. The left-right value tree is used to store marks to find which dimension node the user hangs on, which has high query efficiency.

_△___ Left and right value tree node sort

Finally, we can obtain the jurisdiction result set of account Zhang SAN’s department and position through the intersection query of two dimensional nodes:

The _△___ dimension governs the intersection calculation

Therefore, according to the characteristics of left and right value tree, all the child nodes of the node can be quickly obtained for the data scene with more searching and less writing, and then the jurisdiction relationship can be efficiently obtained to judge the data permission.

3.4 High Performance High availability authentication service

As shown in the figure below, the platform caches the account and permission data to BDRP and preferentially determines the permission through the cache. At the same time, the platform is deployed in suzhou, Beijing, and Guangzhou for remote Dr. The gateway service removes unavailable instances through load balancing policies and health checks. The gateway and platform can ensure 99.999% service stability for two consecutive years through multi-level bottom-caching, degraded DB, and flow control fuses.

_△___ Multi-level cache and fuse

Four,

This paper mainly introduces the account login service of Baidu ToB vertical account permission platform and the design of permission service:

  • The design and practice of single sign-on (SSO) are introduced in detail, and the security and reliability of login services are guaranteed by staged session control and various means.

  • Combined with an example, this paper completely introduces the function authentication of complex business through GD-RBAC and equity package model, and flexibly realizes data authority governance through multi-dimensional authentication, and helps businesses and customers to complete authority control simply and conveniently.

In the future, the platform will continue to enrich the ability of account and permission, continuously improve the stability of service, uphold the concept of “technology for product service” to provide one-stop account and permission solutions to help ToB vertical business lines better play the value of business products.

5. Introduction to the author

This article is co-written by Baidu MEG ToB, aifanfan Luban team members:

  • Corwin: Senior R&D engineer, responsible for multiple business directions successively, good at platform and business system architecture design, and solve business pain points with technology;

  • Tao: Senior R&D engineer, responsible for business foundation, operation support and other related businesses, good at distributed and system design.

Recommended reading:

Input visualization methods in visual Transformer

In-depth understanding of WKWebView (Render) – DOM tree construction

In-depth understanding of WKWebView (Introduction) – WebKit source debugging and analysis

GDP Streaming RPC design

Baidu APP video decoding optimization