Identity Provisioning

计算机网络 authorization authentication 授权验证 identity

计算机/计算机网络

发布日期: 2021-05-23

更新日期: 2021-06-01

文章字数: 2.7k

阅读时长: 9 分

阅读次数:

第一步是常见一个 identity。“provisioning” 指的就是创建 identity 和 account。

名词：legacy system 遗留系统

1. Provisioning Options

对于应用程序开发者来说，identity provisioning 包括获取用户并为其创建账户和 identity profile。可选的方法如下：

用户通过填写注册表单注册
邀请用户注册
利用现有的的用户数据存储库
利用现有的用户身份存储服务
管理员或自动化创建用户身份

上述方法不是互斥的，有些时候需要组合使用。

self-registration

一个选项是让用户自己注册，并通过 self-registration 提供身份信息。这需要吸引用户到你的站点，填写注册表单然后保存这些信息。这是面向消费者用户的站点的常用做法，你需要设计注册表单，并提供有关信息收集的隐私声明并在计划使用搜集的信息时获得用户许可。

使用自注册表单（self-registration form），你可以控制用户的注册体验，自定义需要的信息。但是填写注册表单可能会阻碍部分用户注册网站。

progressive profiling 渐进式收集

你可以使用渐进式的收集方式来收集用户信息，而不是在注册表单要求用户填写所有信息。使用渐进式收集，用户在注册时仅仅需要提供最少量的必须信息，如果用户后续操作需要更多的信息，则那个时候再要求用户提供即可。或者，再经过一段时间或一定次数登录后再收集额外信息。这可以提供更好的注册体验。

Invite-Only Registration

一种自注册方式是仅接受邀请制注册。这种情形下，会邀请特定用户注册。注册邀请可以是其他用户发出的，也可以是网站管理员发出。被邀请者将会得到一个指向注册页面的链接。如果管理员邀请时已经提供了所需的账户数据，则可能只涉及电子邮件地址验证和/或密码重置。这种技术对于邀请特定用户参与早起版本的试用可能很有用。

这种注册方式中注册表单的访问权剑仙与被邀请人。邀请可以通过电子邮件等渠道发送，并包含注册链接。注册页面可以锁定被邀请人的电子邮件地址或手机号码，使其在注册时不更更改，以防止不被邀请的人窃取邀请并注册。如果有必要，邀请的链接还会有过期时间，并且通常每个邀请都被跟踪，因此只能使用一次。

2. Identity Migration 身份迁移

如果用户什么已经存在，可以将其迁移到新的存储库给新的应用使用。这样用户无需再次注册。大多数用户配置文件的数据可以被直接迁移，但是密码的迁移是一个挑战。密码通常以散列格式存储。每次用户登录并输入密码时，会将其进行哈希，然后将哈希值与存储库中的哈希值比较。以散列格式存储密码可以防止管理员看到明文密码，并且如果存储库被盗，黑客也很难使用这些哈希值破坏用户账户。

由于散列算法的不同，一个系统中的散列密码不一定能偶被ing一个系统使用。如果两个系统使用不同的散列算法，则不可能将密码从一个系统移到另一个系统。此时，可以考虑如下将 identity 迁移到新系统的方案。

支持原有的哈希算法

在新系统中支持原系统的哈希算法。这需要新系统能根据账户的不同使用不同的哈希算法。

优点
- 无需用户重置密码
- 迁移原来的所有密码
缺点
- 需要支持遗留系统的哈希算法以及根据账户使用不同哈希算法
- 遗留系统的哈希算法可能不安全

Bulk Identity Migration

这种方式将用户除密码外的数据导入新系统，新系统会给每个用户发送一个唯一的密码重置链接，以在新系统中为其建立一个新密码。这需要遗留系统的身份信息中包含邮件地址信息，且通过电子邮件发送的密码重置链接是足够安全的。另外，用户需要提前得到关于密码迁移的通知，以防止用户将密码重置邮件视为垃圾邮件或者钓鱼攻击（phishing attacy）邮件。如果强制用户重置密码是可接受的，那么可以一次性批量转换，然后停用遗留系统。

用户的逐步迁移

逐步迁移比批量迁移更友好，具体做法是：需要有一个登录机制提示用户输入凭证，然后在遗留系统中进行验证，如果验证通过，则将此身份和输入的凭证存储在新系统中——用户输入的密码在遗留系统验证后，由新系统散列算法散列后在新系统存储。这种做法会把迁移新登录用户的数据，并且要求新系统可以直接访问遗留系统验证密码并获取 identity 的相关信息。缺点是，在迁移完成之前，遗留系统需要一直运行，并且，对于非活动账户，无法完成迁移。

对于无法迁移的非活动账户，你可以设置一个截止日期，并决定如何处理截止日期之后还未完成迁移的用户信息。一种可能的方案是将这些账户设为无效账户并丢弃。另一种方式是使用前文所述的bulk migration 方式，然后遗留系统就可以退役了。你可能只希望迁移那些有理由相信将来会再次激活的 identity。如果您没有迁移所有剩余的 identities，则应该考虑保留未迁移identity的帐户标识，以防止将来新帐户使用这些标识。

当然，身份未完成迁移的用户可能会忘记密码，此时用户可以使用新系统来输入电子邮件来重置密码。然后直接在新系统中创建中护，并从遗留系统中根据邮件信息获得与之相关的账户信息。

3. 管理账户创建

为了创建账户和 identity，另一个方案是有一个管理员或者自动化流程来创建它们。这需要考虑：

组织的规模
常见新账户的频率
创建时是否需要跨域

手动创建

管理员手动创建账户适用于用户很少的情形。对于很小规模的组织，实现自动化流程可能不太值得，所以可以规定好账户创建流程并创建 checklist 来确保账户的创建遵循规定的步骤。如果使用密码作为用户的登录凭证，应该确保管理员无法获知用户密码，这可以通过给用户发送密码重置链接或者在用户首次登录时要求重置密码实现。

自动创建

这种方式常用于员工的 identity。当一位新员工加入公司时，会自动使用 HR （Human Resource）系统中的信息为其创建一个账户。对于大公司而言，这可以提高效率。

跨域账户创建

一些情况下，开通账户可能需要跨域：

在公司外部的 SaaS 程序维护员工账户
在公司内部存储合作伙伴的账户
在面向业务的应用中维护客户的用户账户
维护合作大学的老师、学生的账户等

理想情况下，现代化的身份验证协议会在用户登录时通过身份令牌（authentication token）的方式将用户配置文件的属性传递给应用程序。但是，跨域账户在以下情形下依然存在：

应用程序没有被设计为可以从 token 中获取身份信息
身份信息太大，无法再身份令牌中传递
用户登陆频率过低，无法保证身份信息的实时性

2015年诞生的行业标准 SCIM（System for Cross-domain Identity Management，跨域身份管理系统）提供了跨域账户的标准化管理方案。

4. 利用现有的 identity service

也可以利用用户在其它身份供应商系统中已有的身份。这允许用户使用已有的账户比如谷歌、微信等账户来登录你的应用。使用这种方式，你的应用将身份验证的功能交由第三方供应商负责，并接受其返回 security token，其中包含用户经过验证的会话（session）以及用户的一些其他信息。

使用这种方式，用户无需填写注册表单，开发者也减少了相关的开发工作，这可以在一定程度上降低风险。并且，如果第三方服务商提供的用户信息不足，你也可以额外收集信息。

5. 身份服务供应商的选择

如果选择第三方供应商，那么需要考虑其身份强度、实用性、可用性等等。身份强度可从下面3个方面衡量：

The validation of the information used to establish the identity
The identity’s implementation that prevents it from being forged or used by others
Recognition of certain issuers of identities as authoritative for a particular domain

下面举几个例子：