基盤となるプラットフォームアーキテクチャのSAASレベル：統一されたID管理システム

https://my.oschina.net/bochs/blog/2248954

業界で統一されたユーザの認証と権限管理領域は、4つの領域に焦点を当て：集中アカウント管理（アカウント）、集中認証管理（認証）、集中管理権限（権限）及び集中監査管理（監査）、図4（a）の管理と呼ばれます。その後、IAM（アイデンティティおよびアクセス管理、すなわちアイデンティティおよびアクセス管理）関連技術の開発が広く、クラウドコンピューティングなどの分野で使用されます。全体的に、関係なく、4AまたはIAMの、将来的にはおそらく他の技術的な解決策のカテゴリ「統一されたアイデンティティガバナンス」のように要約することができます。提案されたデザインのアイデア統一アイデンティティ管理システム（統合ID管理システム）の「統一アイデンティティガバナンス」の概念に基づいています。

統一されたアイデンティティ管理システム（統合ID管理システム）

（UIMSと呼ばれる）統一アイデンティティ管理システムは、マルチテナントソフトウェアアーキテクチャアップグレード版、基本的なシステムの通常プラットフォーム全体のアカウントと権限の管理および制御、プラットフォーム、認証、ユーザー認証、アクセス制御、およびその他の行動の下にあるすべてのシステムのアカウント管理と考えることができますシステムを通じて対処されなければならない、アカウントのパスワード管理、基本的なデータ管理、著作権管理の役割を提供しています。「統一されたアイデンティティ管理」の概念に基づいてUIMSは、2つのアカウントシステム、基本的な権利と基本的な情報モジュールモジュール3つのモジュールに分割することができます。アカウント組織エンティティに2つのアカウントシステムが数を占め、2種類のエンティティーを占めており、個々の組織の実体に属するエンティティは、任意の組織ではなく、従属エンティティ、個人や団体は、同時に複数の組織エンティティに属することもあり、基本的な権限モジュール組織エンティティと、そのような組織エンティティ名、住所、法的、個人エンティティ名、電話番号、性別、その他の基本的な情報として、個々のエンティティを記述する基本的な情報のための基本的な情報モジュール、一元管理および承認のための各業務システムのリソースのアクセス権。UIMSは、各サブシステムに接続するための統一されたAPIを提供しています。

ビューのプラットフォーム全体のポイントの観点から、上記の機能とサービスにUIMSの添加は、また、次の要件を満たしている必要があります。

番号	需要	説明
1	ソフトウェアライセンス	クラウドプラットフォームの支払い承認メカニズム、時間に応じて、機能、およびその支払ったライセンスの数
2	組織定住	これは、組織がプラットフォームへの参加を適用するためのイニシアチブを取ることができます
3	確認済み	個人実名認証、実名認証機関
4	資格審査	名誉やレビューの証明書を取得するなど、品質監査、個人や組織、
5	結合組織	組織との関係を確立するための組織をバインドする個人アカウント
6	組織のアンバンドリング	個人アカウントと組織のアンバンドリング
7	アカウントのキャンセル	個人アカウントはオフに書き込まれ、すべての個人情報やファイルを破壊します
8	統一化ログイン	それSSO
9	統一登録	統一されたユーザーの登録ページを提供するために、

したがって、機能的な観点からUIMSは、次のモジュールに分割することができます。

一）功能

    系统设置 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

>調整機能に結び付け、組織を結合し、あなたは、「組織管理エンティティ」または「個別のアカウント管理」機能を置くことができます。組織が、業務システムに関連付けられているかどうかを、機能的なアンバンドリングに結び付け、以下に記載されることに留意すべきです。

第二に、2つのアカウントシステムと基本的権利モジュール

「統一されたアイデンティティガバナンス」の考え方に基づき、二段アカウントシステムSAASのためのマルチレベルのシステム統合プラットフォーム（UIMSは、インターフェイスを提供します）。二つのカテゴリアカウントのアカウントシステムが組織エンティティと個々のエンティティ（以下、ユーザの分類を参照）の2種類に分割されます。個々のエンティティは、（エンティティが複数の組織に属していてもよい）組織エンティティに従属することができる、または従属ではないかもしれません。個々のアカウントシステムとアカウントシステムの組織は、2つのシステムのエンティティの機能やサービスのほとんどがお互いを乱すことなく独立して使用することもできるが、同じではありませんクラウドプラットフォームに特権を享受しますが、一部の機能やサービスが異なります。

1.基本原則

SAASプラットフォームレベルモードのアカウントシステムは、以下の基本的な原則に従ってください：

個人口座統一の原則：個人口座は一度登録でとUIMSログインの両方、ネットワーク全体のラインカードおよびSSOのように、すべての共通のプラットフォームを登録します。
サービス機関の独立の原則：各サブシステムの権限システムが独立して管理されています。「個人アカウント統一原理は、」明らかに統一されたアカウントのシステムですが、各サブシステムのために、データアクセス許可を表示するために、各アカウントのために使用することができる機能やサービスは、このようなXXXの会社（組織）として、独立して維持することができます - R＆D T3グループ（ユーザーグループ） - ジョー・スミス（ユーザー） - R＆D人材（役割）リソース権限を持つCRMシステム、内（下記参照）、そのリソースは、OAシステムに権限を持っているが、確かに一貫性がありませんA。
組織エンティティの分離原理は：異なる組織エンティティ間で、互いに分離され、独立して管理されます。各組織エンティティは、自分の組織体制、アカウントのシステムと権限システムを編成することができます。異なる組織エンティティリソースのアクセス権も隔離されています。
所属分離の原則：個々のアカウントや組織エンティティの所属は、別々のビジネス・システムに基づいていますが存在し、個人口座の明確なだけで統一されたネットワーク全体が、組織エンティティ、所属していない均一な「アカウントの団結の個人主義」、およびこれは隔離されています。たとえば、CRMシステムでは、ジョー・スミス（ユーザー）XXXX会社（組織）に属するが、OAシステムでは、ジョー・スミス（ユーザー）デフォルトでは、どのような組織への所属が特定の業務システムに影響され、関連会社ではありません。実際には、この原則は、ビジネス・ロジックとビジネスシナリオによっては、必須ではありません。あなたが所属の管理を簡素化したい場合は、私たちは、個々にかかわらず、業務システムの、プラットフォーム全体の統一主体の組織と提携を占めるというこの原則に従うことはできませんが、これは、プラットフォームの柔軟性と拡張性を軽減します。通常、我々は、柔軟性と複雑さとのトレードオフを行います。

権限の原則2.

RBACはのOS-RBACの概念を使用して権限システムのプラットフォームの原則に似ています。

OS：O組織は、組織を代表して、Sシステムビジネスシステムのために、その権威が組織エンティティとダブルインパクトのビジネスシステムの対象となります。
RBAC：ロールベースのアクセス制御。
OS-RBAC：組織エンティティ - ビジネスシステム - ユーザー - 役割 - アイデンティティの権限。2例に分け：一つは、個々のアカウントの下位組織であり、他には、階層組織個人アカウント、後者のない組織ではないだけでなく、定義されたRBAC権限に準拠し、かつシステムは、組織権限識別子が空であることができます。
リソース識別：論理リソースと物理リソースに分割されます。メニュー、ページ、フォーム、設定ボタン、ボタン、フィールド、および他の機能のリソース、または人事ファイル、出席記録、ジョブ履歴、位置データ、統合、電子財布や他のデータリソースとしてロジック・リソース等の椅子、スツール、コンピュータなどの物理的なリソース、車や他の物理的な資産は、時々、ロジック・リソースの別の部分は、このようなように、電子写真、ビデオファイル、音楽ファイルやなどの物理リソース、のように要約することができます。
識別条件：拘束権限、組織主可視範囲が定義され、時間制限、定義された領域などが挙げられます。たとえば、「財務省は」可視範囲定義された組織構造に属する11月2日まで有効な特権見え財政の唯一の省は、「11月2日までの」時間制限です。
権限のシンボル：許可データのいくつかを見るために、アカウントのエンティティが指定された条件の下での機能へのアクセス権を持って識別します。リソースの識別とアイデンティティと役割に関連付けられている許可IDに関連付けられた条件を識別するための権限、役割がユーザーに関連付けられています。例えば、ジョー・スミス（ユーザー） - R＆D担当者（役割）は - すべての人事ファイルによる調査へのアクセス権を変更するには、「R＆D」を持っています。
ビジネスシステム識別子：伝統的なリソース権限で「独立したサービスの権限の原則」バインドは異なるよう、企業のCRMシステムなどの特定のビジネス・システムに関連するすべての権限識別子は、特定の権限を特定の業務システムであるということですメニュー、フォーム、ページ、ボタン、画像、およびその他のリソースなどの業務システムとの直接的な関係を持っています。
権利ポリシーグループ：グループポリシーの権限はアクセス権の設定を簡素化するための補助として、あなたは実用的なアプリケーションでのポリシーグループを作成することはできません、OG-RBACに基づいて設定されています。ポリシーグループは、プラットフォームレベルのポリシーグループと業務・システム・レベルのポリシーグループに分けて、2つの戦略の範囲は、個人口座の無下部組織を除き、組織エンティティの同じセットに限定されていました。同様の役割を持つポリシー・グループ、パーミッションは、ポリシー・グループにリソースをバインドすることができますが、違いは、プラットフォームレベルのポリシーグループは、業務システム間で結合プラットフォームレベルのリソースの許可することができます。複数のサブシステム間でアカウントシステムなので、各サブシステムの下で定義され、以下の「独立したサービスの権限の原則は、」アクセス権の設定のセットを行う必要があり、操作がより複雑なので、完全な使用が大幅ポリシー・グループの権限の構成を簡素化することができます。プラットフォームは、エンドユーザーが直接ポリシー・グループを選択することができ、複数のセットの共通ポリシーグループに組み込むことができ、ポリシーは、グループ単位に基づくことができ、変更すること。これは、ポリシーグループのスコープは、ビジネスポリシーグループのシステムにまたがることができ、同じ組織のエンティティに限られていたことは注目に値するが、いくつかの組織エンティティに同時に作用することはできません。
権限の交差点：業務用RBAC2の静的分離 - 相互排他的なコントラスト、マルチプラットフォームの役割の権限とセット設計の原則の役割。

RBACモデル

>例 "権限を識別" エンタープライズCRMシステムでは、[1]、2019年3月[5]全ての人員の広東領域におけるBaiduの技術[3]、R＆Dセンターの[2]の前に5号、[4] [6]ファイルを読み取り専用のアクセスを[7]。

[1]サービスシステム識別子。
[2]の条件を識別した：制限時間。
[3]組織エンティティ識別子。
同定された[4]の状態：可視範囲に定義組織。
[5]の条件を識別した：領域の範囲を規定します。
[6]リソース識別子。
[7]アクセス許可のタイプ。

3.所属コム

>簡単にするために、我々は、ビジネスシステムとユーザエンティティ組織エンティティの所属とは何の関係もありません「所属の分離の原則」に準拠しません。関連するシステムのエンティティタイプは次のとおりです。

ビジネスシステム（システム同定）
サービスアカウント（クライアント）
個人アカウントエンティティ
組織のアカウントのエンティティ
組織
ユーザグループ（非必須）
役割実体
権限のエンティティ
リソースエンティティ
エンティティ定義された条件
権利ポリシー・グループ（非必須）

エンティティに関連付けられている3.1の強い組織エンティティ

> 基于『组织实体隔离原则』，这类实体类型不能脱离组织实体独立存在。

组织架构
角色实体
权限实体
资源实体
限定条件实体

> 由于组织架构不能脱离组织实体单独存在，因此当用户实体绑定组织架构时，该用户实体必须隶属于该组织架构所从属的组织实体。同理可知以下从属关系遵从同样的约束——即每对关系的两个实体对象必须属于相同的组织实体：

用户与角色
角色与权限
资源与权限
限定条件与权限

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 应提供相应的页面完成账户注销的操作。

九）私有化部署

原則として、展開の民営化を検討しますが、特定のクライアントのために、展開を民営化することを拒否しました。民営化の展開バージョンのソフトウェアアーキテクチャの設計で考慮すべき課題、ビジネスシステムをアップグレードし、分離技術システムの原則に従うことをしようと、民間バージョンの展開を最大化するためにアップグレードサービスを提供するために、共通モジュールを取り出しました。

V.の概要

全体的に、統一されたID管理システムが行うので、いくつかあります。

定義されたエンティティ

ビジネスシステムエンティティ
サービスアカウントのエンティティ（クライアント）
組織の実体
組織
個々のエンティティ
役割実体
権利のロゴ
リソース識別
条件のロゴ

エンティティ間の関係に対処、およびデータ構造を提供
認証サービスAPIとAPIを提供するために、
その他の機能：統合登録機能（ページやプロセス）、統一化ログイン機能、ソフトウェアライセンス、組織は、組織化バインド/バインド解除、資格審査を解決しました。