Personal Reflections: construction in Taiwan - Taiwan -V1 users

 

Design ideas

 

Preface

I was in Taiwan from the business point of users, combined with a unified identity management system (4A or IAM) to design the user station. I have benefited from "basic level SAAS platform architecture: a unified identity management system," the article, combined with the basis of this article on the company's existing business and some will be revised.

Some concepts:

4A Management : centralized account management (Account), centralized authentication management (Authentication), centralized management authorization (Authorization) and centralized audit management (Audit)

IAM : the Identity and Access Management, namely Identity and Access Management

Point of departure

I mainly use the table from the user to the idea of ​​the entire business structure. User station, located between the station and the data service station can be seen as a special kind of business units.

Users in Taiwan mainly doing?

For 2C:

  • I need to sign it
  • How I login, password phone, SMS verification code, third-party login (micro letter, QQ, Weibo, etc.)
  • How do I sign up, phone number registered, registered mail
  • How can I log off accounts
  • Do I need real names, how real name

For the purposes of 2B, many user accounts are assigned by the administrator 2B business systems (most CRM, ERP, OA), now also supports the invitation sent by the administrator (both 2B 2C business there, such as nails, teambition , graphite, etc.)

  • How to register organizations
  • How to organize real name
  • How to log organization (organization administrators how to log on)
  • Staff how to log, phone password, SMS verification code, third-party login (micro letter, QQ, Weibo, etc.), account name / ID
  • How to create, delete, disable employee accounts
  • Administrators how staff are invited to join this virtual "organization"
  • How organizations assign staff permissions (access control)

In summary, the user station to meet the administrative account (organizations and individuals), the basic needs permission.

Let's dial back the time line appears before the user station. Prior to enterprise business systems is the responsibility of the various departments, such as the well-known OA system, financial systems, CRM and ERP systems, which many of them are made by a department to promote the use of the company then. This time will find that data in these systems is not universal, each system needs to staff and organize entry again. Once the employee changes, then all business systems need to update all over again.

To solve this problem, some systems it provides the ability to interface or imported data, allowing a system synchronization information to other systems. But this is also a problem, the data is synchronized, but there is no synchronization log on, employees need to work in order after logging in, you can not log in once all associated systems. Thus was born 4A unified identity management platform single sign-on and behind the former to solve a single login for all systems (as well as the follow-up single points of exit), which addresses the user account, authentication, authorization, auditing four questions.

Users in Taiwan inherited the core functionality 4A account management platform, authorization, authentication and authorization are generally placed API gateway (micro Services Architecture). For this reason I based unified identity management to design the company's customers in Taiwan.

Unified identity management capabilities

Unified identity management must have the account management of all systems under management platforms, authentication, user authorization, access control, etc., and provide account password management to other systems, personal / organizational functions basic information management, role permissions.

From a platform point of view, the user platform is divided into two categories, one is the individual user, one is the user organization (there is a class system users, hidden). Individual users are very common, all of the applications and the C-terminal part of the B-side applications are based on individual user system.

On the organization of the user (account) In fact, some platforms are also very common, such as micro-channel personal public numbers and corporate public numbers; bank company accounts and personal accounts, Alipay and micro-channel has a similar account; Apple developer account personal corporate division. Note that most organizations accounts can be bound to a personal account.

Overall, this consent identity management should meet the following requirements

Numbering

demand

description

1

Unified login

SSO

 

Unified registration

Unified user registration page

 

Verified

 

 

Account cancellation

 

 

 

 

From a functional point of view, can be divided into the following modules, see FIG brain

  • Account
  • Authenticate
  • Organization Management
  • authority management
  • Authorization Management
  • Authentication Center
  • System Management

 

Accounts and rights management

Mentioned earlier, uniform identity management system uses a Class 2 accounts, personal accounts and corporate accounts. Involved in a multi-tenant platform concept, personal accounts and corporate accounts are indispensable. In general, individual accounts can belong to an organization.

 

The basic principle

Accounts and permissions management following principles

  • Personal accounts unifying principle: personal accounts once registered, all common platforms, like the whole network line card and SSO.
  • Service authority independent principles: rights system each subsystem is independent, but is maintained by the user in a unified station management. "Personal Account unified principle" is clearly a unified account system, but for each subsystem, features and services that can be used for each account, to view data permissions can be maintained independently, such as XXX company (organization) - R & D T3 group (user groups) - Joe Smith (user) - R & D personnel (role) in the CRM system, with resource rights (see below), its resources have authority in the OA system is certainly not consistent of.
  • Organizational entities segregation principle: between different organizational entities, are isolated from each other, independently managed. Each organizational entity may organize their own organizational system, account system and permissions system. Different organizational entities resource permissions are also isolated.
  • Affiliation isolation principles: affiliation of individual accounts and organizational entities are based on separate business systems exist, "personal principle of unity of account" clear only unified whole network of personal accounts, but organizational entities, affiliation and no uniform, and It is isolated. For example, in the CRM system, Joe Smith (users) belonging to XXXX Company (organization), but in the OA system, Joe Smith (user) default is not an affiliate, affiliation to any organization is affected by specific business systems. In fact, this principle is not mandatory, depending on their business logic and business scenarios. If you want to simplify the management of affiliation, we can not follow this principle that the individual accounts affiliation with the organization of the whole platform unified entity, regardless of the business system, but this will reduce the flexibility and scalability of the platform. Usually do a trade-off between flexibility and complexity.

 

Rights principles

The user sets permissions system is based on RBAC concept, the RBAC RBAC is based on resources rather than role-based RBAC

  • Permissions business systems are independent of each other, no dependencies
  • Data of the organizations are mutually independent and isolated
  • Permissions business systems to comply with resource-based RBAC
  • Data authority is limited to data rules
  • Permissions union: static separation of duties RBAC2 - mutually exclusive roles opposite principle, permission to take multi-role platform and set design. That is, in a business system, the user can have multiple roles. At this point equal to each user role permissions in the permissions of the business system and set

To meet the above points, the system must have permission system identification; data resources organized to identify not only the authority, but also must have identification and creator identification department, department logo and is easy to distinguish the main creator of consumers and producers.

ps: not currently designing the user group concept and role groups

Spread

Mentioned in the preamble to the "basic level SAAS platform architecture - a unified identity management system," the article, the authors use the OS-RBAC permissions system, where O is Orgnization organization, S is Systerm system. Explain this system by the organization and system privileges Description dual constraints.

This I agree, permission is dependent on the system, the data depends on the organization. This is particularly evident in multi-tenant system, the administrator can not see the A's B's data, since A and B are two different organizations; likewise, A company's organizational structure, authority system can be completely and Company B same.

Consider the company's business platform did not reach the level of SAAS, mainly for personal use and business and third-party developers access to use. In order to reduce complexity, I reduce the impact of the organization on the right. In short, in a business system, function rights for all administrators is the same (except for data rights, subject to its organizational impact), due to the role by the system is not affected by organizational impact.

user type

The following diagram from the "basic level SAAS platform architecture - a unified identity management system," which profiles the user types in great detail. I will organize users and industrial users are on the organization user concept, correspondence and organization accounts foregoing. .

 

 

 

Service Decomposition

Service under the micro-service architecture decomposition in two ways, one is based on the operational capacity of decomposition way, one is based on DDD field drive sub-domain decomposition. Because I'm still learning DDD field drive, so the first to break down the service based on operational capacity.

The following are the specific services and service capacity:

1, account class service

  • Account Management Services
  • Registration Service
  • Logout Service

 

2, permission class service

  • Role services:
  • Permissions Services:

 

3, type of service organization

  • Organization and management service
  • Organization management services

 

4, the authorization class service

  • Authorized service: bind / unbind role permissions to bind / unbind user roles, bind / unbind user and the system, binding the user and the organization

 

5, the authentication service class

  • Login authentication service: login configuration, log on risk control and operational capacity login authentication 3
  • 其它访问鉴权:负责外部应用访问内部服务的鉴权

 

6、认证类服务

  • 认证服务:包含个人实名认证、组织实名认证和人证资质审核3个业务能力

 

7、系统类服务

  • 系统管理服务:负责系统的增删改查

 

 

 

 

 

 

参考链接

1、平台级SAAS架构的基础:统一身份管理系统

发布了11 篇原创文章 · 获赞 18 · 访问量 2万+

Guess you like

Origin blog.csdn.net/wweiru/article/details/104264293