https://my.oschina.net/bochs/blog/2248954
In the industry a unified user authentication and authorization management areas, focusing on four areas: centralized account management (Account), centralized authentication management (Authentication), centralized management authorization (Authorization) and centralized audit management (Audit), referred to as 4A management. Later, the development of the IAM (Identity and Access Management, namely Identity and Access Management) related technology, widely used in cloud computing and other fields. Overall, regardless of 4A or IAM and in the future possibly other technical solutions, can be summarized as category "unified identity governance" of. Based on the concept of "unified identity governance" of the proposed design ideas unified identity management system (Unified Identity Management System) is.
A unified identity management system (Unified Identity Management System)
Unified identity management system (referred to as UIMS) can be considered a multi-tenant software architecture upgraded version, usually the entire platform accounts and privileges management and control of the basic system, account management of all systems under the platform, authentication, user authorization, access control and other behavior must be dealt with through the system, provide an account password management, basic data management, the role of rights management. UIMS based on the concept of "unified identity management" can be divided into two accounts system, basic rights and basic information module module three modules. Wherein the two account system into account organizational entities account number and account two types of entities, entities belonging to individual organizational entity, any tissue may not subordinate entities, individuals and entities may simultaneously belong to multiple organizational entities; basic permissions module the resource permissions for each business system for unified management and authorization; basic information modules for basic information describing the organizational entities and individual entities, such as organizational entity name, address, legal, personal entity name, telephone number, gender and other basic information. UIMS provide a unified API to connect with each subsystem.
From the perspective of the entire platform point of view, UIMS addition to the above features and services, should also meet the following requirements:
| Numbering | demand | description |
|---|---|---|
| 1 | Software Licensing | Cloud platform payment authorization mechanism, according to time, function, and so the number of paid licenses |
| 2 | Organization settled | It allows organizations to take the initiative to apply to join the platform |
| 3 | Verified | Personal real-name certification, real-name certification organization |
| 4 | Qualification examination | Quality audit individuals and organizations, such as to obtain a certificate of honor or review |
| 5 | Binding organization | Personal account to bind organizations to establish relationships with organizations |
| 6 | Organizational unbundling | Personal accounts and organization unbundling |
| 7 | Account cancellation | Personal accounts written off, and destroy all personal information and files |
| 8 | Unified login | That SSO |
| 9 | Unified registration | To provide a unified user registration page |
Thus, from a functional perspective UIMS can be divided into the following modules:
一）功能
系统设置 System Configuration
系统标识管理 System Identifiers Management
服务账户管理 Service Accounts Management
账户实体管理 Account Entities Management
组织实体管理 Organization Entities Management
组织架构管理 Organization Management
个体账户管理 Individual Accounts Management
账户权限管理 Account Permissions Management
用户组管理 User Group Management
角色管理 User Roles Management
资源权限管理 Permission Resources Management
权限策略组管理 Permission Group Management
认证审核管理 Authentication Management
个人认证管理 Individual Authentication Management
组织认证管理 Organization Authentication Management
资质审核管理 Qualification Management
付费授权管理 Authorization Management
组织授权管理 Organization Authorization Management
二）页面
统一注册页面 Unified Signup Page
统一登录页面 Unified Signin Page
组织入驻页面 Organization Signup Page
个人实名认证页面 Individual Authentication Page
组织实名认证页面 Organization Authentication Page
三）API
鉴权相关的APIs
业务相关的APIs
> Which bind the organization tied to reconciliation function, you can put "organization management entity" or "Individual Account Management" function. It should be noted that the organization tied to functional unbundling, whether associated with business systems, will be set forth below.
Second, the two account system and basic rights module
Based on the concept of "unified identity governance", the two-stage account system (UIMS provides the interface) multi-level system integration platform for SAAS. Two categories account account system will be divided into two types of organizational entities and individual entities (see user classification below). Individual entities may be slaved to tissue entities (entities may belong to multiple organizations), or may not be dependent. Individual account system and account system organizations enjoyed privileges in the cloud platform is not the same, although most of the entity functions and services of the two systems can be used independently without disturbing each other, but some features and services vary.
1. Basic Principles
SAAS platform-level mode account system should follow the following basic principles:
- Personal accounts unifying principle: personal accounts once registered, all common platforms, like the whole network line card and SSO, both in registration and login UIMS.
- Service authority independent principles: permission system for each subsystem is independently managed. "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 we do a trade-off between flexibility and complexity.
2. The principle of authority
RBAC is similar to the principle of authority system platform using OS-RBAC concept of:
- OS: O Organization on behalf of the organization, S for System business systems, that authority is subject to organizational entities and business system of double impact.
- RBAC: Role-based access control.
- OS-RBAC: organizational entities - business systems - user - role - identity permissions. Divided into two cases: one is a subordinate organization of the individual account; the other is no hierarchical organization personal account, the latter no tissue, but also comply with RBAC permissions defined, and which system allows organizations authority identifier is empty.
- Resource identification: divided into logical resources and physical resources. Logic resources such as menus, pages, forms, buttons set, buttons, fields, and other functional resources, or personnel files, attendance records, job history, location data, integration, electronic wallets and other data resources; physical resources such as chairs, stools, computer, vehicles and other physical assets, sometimes another part of the logic resources can be summarized as physical resources, such as electronic pictures, video files, music files and so on.
- Identifying conditions: constraint authority, organization main visible range is defined, time-limited, defined area and the like. For example, a privilege only the Ministry of Finance visible, valid until November 2, where "the Finance Ministry" belonging to the visible range defined organizational structure, "until November 2" is the time limit.
- Permissions symbol: To identify the account entity has access to a function under specified conditions, to see some of the permissions data. Resource identification and identity and authority to identify conditions associated with the authorization ID associated with the role, the role associated with the user. For example Joe Smith (user) - R & D personnel (role) - have "R & D" to change the permissions on the investigation by all personnel files.
- Business system identifier: bound "independent service authority principle" with traditional resource rights is different is that all authority identifier associated with a specific business systems such as enterprise CRM system is a business system that identifies specific permissions have a direct relationship with business systems, such as menus, forms, pages, buttons, images, and other resources.
- Rights Policy Group: Group Policy permissions are set on the basis of the OG-RBAC, as an aid to simplify the configuration of permissions, you can not create a policy group in practical applications. Policy Group is divided into the platform level policy groups and business systems-level policy group, the scope of the two strategies was limited to the same set of organizational entities, except for no subordinate organization of personal accounts. Policy group with similar roles, permissions can bind resources to a policy group, but the difference is, platform-level policy group can be platform-level resource permissions binding across business systems. Because the account system across multiple subsystems, under defined following the "principle of independent service authority" of each subsystem needs to do a set of permissions configuration, operation is more complicated, so full use can greatly simplify the policy group permissions configuration. Platform can be built into multiple sets common policy group, end users can directly choose the policy group, the policy can be based on a group basis, be modified. It is worth noting that the scope of the policy group was limited to the same organizational entity that can span business policy group systems, but can not act simultaneously on several organizational entities.
- Permissions intersection: static separation of duties RBAC2 - the role of the principle of mutually exclusive contrast, multi-platform role permissions and set design.
> "Permission identifies" Example: In the enterprise CRM system [1], in March 2019 No. 5 before [2], on Baidu technology [3], R & D centers [4], in the Guangdong region [5] of all personnel file [6] have read-only access [7].
- [1] service system identifier;
- [2] identified conditions: time limit;
- [3] organizational entity identifier;
- [4] Condition identified: the visible range defined organization;
- [5] identified conditions: defining a region range;
- [6] The resource identifier;
- [7] permission type.
3. affiliation comb
> For simplicity, we will not comply with "affiliation isolation principle", that has nothing to do with the user entity organizational entity affiliation with business systems. Entity types of systems involved are:
- Business System (System Identification)
- Services account (client)
- Personal Account entity
- Organizational account entity
- Organization
- User group (non-mandatory)
- Role entity
- Permissions entity
- Resource entity
- Entity defined conditions
- Rights Policy Group (non-required)
3.1 strong organizational entities associated with entities
> 基于『组织实体隔离原则』，这类实体类型不能脱离组织实体独立存在。
- 组织架构
- 角色实体
- 权限实体
- 资源实体
- 限定条件实体
> 由于组织架构不能脱离组织实体单独存在，因此当用户实体绑定组织架构时，该用户实体必须隶属于该组织架构所从属的组织实体。同理可知以下从属关系遵从同样的约束——即每对关系的两个实体对象必须属于相同的组织实体：
- 用户与角色
- 角色与权限
- 资源与权限
- 限定条件与权限
3.2 与业务系统强关联的实体
> 基于『业务系统隔离原则』，这类实体类型不能脱离业务系统独立存在。
- 权限实体
- 资源实体
- 限定条件实体
4. 实体类型
基于以上各项原则，实体类型又分为以下几种情况：
- 组织实体（未认证）：在组织实体的模式下，可以按照组织的管理要求，独立设置一套组织架构、账户和数据权限体系，比如设置下属企业、分公司、部门、岗位职务、角色权限，组织实体缺省分配一个管理员帐户，拥有全部权限，由管理员初始化配置信息。
- 组织实体（已认证）：拥有未认证组织实体的所有权利，但已认证的实体通常拥有更多的配额更少的功能限制，此外有些特定的业务功能和业务流程，必须是实名认证的实体才能使用，比如支付和交易。
- 个人实体（未认证）：在个人实体的模式下，享受的权利由具体的业务系统决定，原则上个人实体作为独立的账户类型，应该享有基本的功能权限和数据权限，如个人中心的各项功能等。
- 个人实体（已认证）：与组织实体（已认证）类似。
- 个人实体（未从属于组织）：未从属组织的个人实体账户，与上述个人实体类型一致。
- 个人实体（从属单个组织）：从属单个组织的个人实体账户，除了具备个人实体账户的原本权利外，还受到组织权限的约束，原本个人实体不享受的权利，可能现在可以享受，原本享受的权利，可能现在不可以享受了。
- 个人实体（从属多个组织）：当个人实体账户从属于多个组织时，除了个人账户原本拥有的权利外，所从属的组织所带来的权利须遵循『组织实体隔离原则』，且受到『从属关系隔离原则』的约束，具体的权利配置由各个业务系统独立管理。这里有两种情况：一是在用户登录时，必须选择所属的组织机构，类似于 LOL 游戏，在登录时须选择所属的区域和服务器；二是在用户登录后，可以自由选择组织实体，类似于阿里云或华为云的区域选择，在用户未选择所属组织时，应当按照未从属于组织的个人实体账户对待。
- 组织管理员：组织管理员拥有该组织内部的全部资源权限，例如可以创建个人账户，在个人未完成首次登录前，可以删除（解雇），修改，在个人完成登录后，则权限移交给了个人；删除（解雇）时，只是个人脱离组织，个人不再拥有组织员工的权限，在组织内的个人工作经历仍然保留，组织清除离职员工，则这些在职经历将不为企业可管理，但个人自己可见，不可变更。
5. 用户分类
6. 组织分类
三、基础信息模块
基础信息，主要针对个人实体和组织实体，如企业工商信息、通用信息等要满足灵活扩展的需求，实体的类型种类繁多，随着业务场景的变化，信息结构的变化也可能比较频繁。在技术上建议采用以下两种方式应对：
1. EAV 数据模型
EAV 即 Entity（实体）-Attribute（属性）-Value（值）数据模型，将传统的 ORM 映射模型——即实体属性与数据库表字段一一对应的模型，变换为实体属性与数据表的行记录一一对应的模型。EAV 模型大大增加了数据映射和相关业务逻辑的复杂程度，但是具备高度的灵活性，能够满足随时变化的信息结构，满足动态变更的实体结构、满足字段级权限控制、满足字段级数据版本历史等功能。
2. 采用松散型数据结构的数据库方案
其中的代表便是 MongoDB：一个介于关系数据库和非关系数据库之间的分布式文件存储数据库产品，在 CAP 理论中属于 CP 范畴，支持松散数据结构，支持复杂的混合数据类型，支持 JSON 和文档存储。采用此方案的优势比较明显，除了能够满足 EAV 模型所具备的大部分功能外，还大大简化了技术复杂度，支持分布式部署，推荐采用此方案。
3. 信息分类
平台的信息主要分为基础信息和业务信息两大类。基础信息分为个人实体信息和组织实体信息，主要描述实体的基本信息、通用信息，与业务相关性不大，例如姓名、性别、身份证号码、手机号码、企业通用信息、企业工商信息等。业务信息由各业务系统自行管理和维护，UIMS 不涉及。
| 实体类别 | 信息类别 | 信息范围 | 备注 |
|---|---|---|---|
| 个人信息 | 基础信息 | 昵称、性别 | 默认公开 |
| 个人信息 | 基础信息 | 身份证信息、籍贯、性别、出生日期、学历、工作履历、电话号码、通信地址、照片、银行卡号 | 须用户授权收集和公开 |
| 个人信息 | 业务信息 | LBS数据 | 须用户授权收集和公开 |
| 个人信息 | 业务信息 | 用户移动终端的设备信息，包括IP地址、Mac地址、操作系统信息、设备型号、识别码等 | 须用户授权收集和公开 |
| 个人信息 | 业务信息 | 用户的行为信息，包括操作记录，cookies，通过平台编辑或传送的文字、图片、语音或视频信息等 | 须用户授权收集和公开 |
| 个人信息 | 业务信息 | 用户喜好、特长、手工标签、自动标签、社交互动信息等 | 须用户授权收集和公开 |
| 组织信息 | 基础信息 | 组织工商信息：名称、法人、营业范围、注册日期、注册资本、通信地址、工商注册号、公司类型、纳税人识别号 | 默认公开，自动审核 |
| 组织信息 | 基础信息 | 组织介绍、品牌介绍、微信公众号、企业官网、对外联络电话、客服电话 | 默认公开，须人工审核 |
| 组织信息 | 基础信息 | 企业资质、股权结构、对外投资、工商登记变更记录、企业年报、公司发展历程、行政许可 | 须组织授权收集和公开 |
| 组织信息 | 基础信息 | 核心团队和成员、融资历程、核心产品、公司规模、知识产权 | 须组织授权收集和公开 |
| 组织信息 | 基础信息 | 组织架构、组织成员档案、司法风险、法律诉讼 | 须组织授权收集和公开 |
所有与信息收集、储存、处理及数据安全有关的书面政策，应当出具《隐私政策》并进行声明。部分组织信息由于可在网上公开查到，且是法定必须公布的信息，因此可以默认公开。
四、其他功能
一）软件授权
基于两级账户体系，建立云平台付费授权机制，针对用户账户和组织账户进行独立授权。根据产品的商业策略，可执行灵活的付费模式：
- 时效限制：年付、季付、月付，不同时效费用不同。
- 功能限制：授权不同的功能，费用不同。
- 数量限制：最大组织数量限制、最大用户数量限制，不同的数量费用不同。
二）组织入驻
UIMS 应提供一个组织实体注册登记的流程，允许组织主动提交基本信息，开户入驻平台。此外，应提供在管理后台手工录入组织开户的功能。
三）实名认证
分为个人账户实名认证和组织账户实名认证，尽量通过技术手段自动执行实名认证的审核过程，减少甚至取消人工干预。UIMS 应提供实名认证的功能和流程。
四）资质审核
资质审核分为两部分：一是部分实体实名认证过程中的人工核查；二是对实体提交的额外资质进行技术或人工审核。
五）组织绑定
基于『从属关系隔离原则』，个人账户应在具体的业务系统中绑定组织账户，绑定过程分为两种类型：一是由组织管理员手工创建的从属个人账户，另一个是个人账户申请加入某个组织。业务系统应该提供此功能和流程。例如，个人注册帐号后，可主动登记绑定组织，对已注册登记的组织则要该组织管理员审核，未在系统中注册登记的组织，则始终处于待审核状态。
六）组织解绑
允许个人账户解除与组织之间的从属关系。解绑分为两种情况：一是个人账户主动解除关系，二是组织管理员解绑、解雇或清除雇员（个人账户）。其中第一种个人解绑的，应当由组织进行审核批准，个人申请解除绑定关系，组织进行审核，但是是否需要审核，应交由具体的业务系统自行决定。
七）间接雇佣（从属）关系
雇佣（从属）关系分为直接雇佣与间接雇佣关系。例如保安员在某保安公司入职（直接雇佣），在某物业作保安（间接雇佣）。考虑两种办法标识间接雇佣关系：
- 增加服务单位（项目点、物业社区）的实体概念
- 利用组织内部的组织机构体系，将间接雇佣单位作为当前组织的分支机构进行处理。
八）账户注销
分为个人账户的注销和组织账户的注销。UIMS 应提供相应的页面完成账户注销的操作。
九）私有化部署
In principle, refused to privatize the deployment, but for a particular client, considering the privatization of deployment. Privatization deployment version upgrade issues to be considered in the design of software architecture, business systems and try to follow the principle of separation technology systems, and pulled out a common module, to provide upgrade services to maximize the deployment of private version.
V. Summary
Overall, unified identity management system to do there are so few:
- Defined entity
- Business system entities
- Services account entity (client)
- Organizational entities
- Organization
- Individual entities
- Role entity
- Rights logo
- Resource identification
- Conditions logo
- Dealing with the relationship between the entities, and provides data structures
- To provide authentication services APIs and APIs
- Additional features: Unified registration function (page and processes), unified login function, software licensing, organization settled, organized bind / unbind, qualification examination.