现代身份指南
Search…
⌃K

第十七章 非常见要求

在本章中,我们将分享一些可能适用于您的项目的不太常见的要求。 在项目早期确定对它们的需求可以帮助您避免意外和项目延迟。 我们围绕人员、帐户和环境三个维度来展开这些场景。

人员

这些需求源于人们在生活或工作中的活动、变化以及关系。

家庭账户

对于可以在家庭成员之间共享的服务(例如电影流媒体),可能需要将多个家庭成员与一个家庭帐户相关联。 此要求适用于保险、数字图书馆、蜂窝服务提供商、医疗保健或传统上在家庭成员之间共享的其他服务。 此外,一个家庭成员可能需要被告知或代表另一个人(例如未成年儿童或老年人)进行交流。 对于此类面向家庭的服务,应用程序可能需要识别与帐户关联的所有家庭成员以及每个家庭成员可以为他人做什么。

临时岗位

在公司环境中,外包商、实习生或合作伙伴有时需要临时帐户。 如果临时账户不受公司正常账户管理流程的约束,则在临时工作关系结束后,它们可能不会被终止。 最佳做法是为临时帐户设置到期日期,并要求临时员工的经理定期批准临时帐户的续订。 如果帐户未续订,则应将其禁用。 临时帐户访问权限所允许的权限的敏感性可以确定帐户审查和续订的适当频率。

状态变更

另一项公司要求涉及从一种身份工作转换为另一种身份的人员,例如临时合同工转变为全职员工身份,反之亦然。 如果临时员工与员工分开注册和管理,但所有来源都输入一个身份提供者,则同一个人的两个帐户可能同时存在,这可能会导致歧义,或者最坏的情况是未经授权的访问。 如果一个人可以从一种状态转换到另一种状态,则应设计流程以避免同一人重复帐户。

没有邮箱地址

许多应用程序需要用户配置文件中的电子邮件地址属性。 但是,可能存在用户没有电子邮件地址的情况。 一些企业不会向不需要在工作中阅读电子邮件的员工发放电子邮件地址。 年幼孩子的父母可能不允许他们拥有电子邮件地址。 某些组织可能会为其用户提供电子邮件地址,但其隐私准则禁止使用电子邮件地址作为帐户标识符。 应用程序可能需要适应没有电子邮件地址或没有电子邮件地址使用限制的用户。

身份联邦

需要支持帐户联邦,同时保持帐户完整的场景。 例如,当一个人终止与雇主的关系时,他们可能需要使用个人帐户来访问他们之前通过雇主身份提供商处的帐户访问的资源。 如果公司向员工提供养老金计划,员工可能会通过其雇主选择的身份提供者登录外部养老金网站。 但是,如果员工辞职,他们在企业身份提供商处的帐户将不复存在。 用户需要将他们在养老金系统中的帐户与其雇主的身份提供者分开,以便他们可以使用养老金系统本地的个人帐户登录。 一般来说,当用户可以断绝与组织的关系,但仍然有权访问他们之前通过联合身份访问过的资源时,就需要联合。

账户

合并和收购

合并和收购可能会带来身份管理挑战。 对于公司而言,拥有一个身份存储库对所有用户进行身份验证是有利的。 当一家公司收购或与另一家公司合并时,两家公司的身份存储库通常会合并,这可能需要解决重复的用户名,以在新合并的实体中实现用户名的唯一性。
更改用户名以消除重复可能会影响应用程序。 当用户通过集中身份提供者的身份验证时,用户的标识符将传递给应用程序。 如果应用程序维护包含用户标识符的用户配置文件或数据记录,则从身份提供者传递给应用程序的标识符必须与应用程序中用户的标识符相匹配。 如果用户的标识符作为合并的一部分发生更改([email protected] 变为[email protected] 或“yy”变为“yang.yu”),身份提供者可能需要转换标识符,以便用户可以通过一个新的标识符,但将他们以前的标识符传递给仍然使用旧标识符的旧应用程序。
或者,可以在应用程序中实现用户标识符的更改。 但是,这应该小心完成,因为除了用户的个人资料之外,它还可能需要更新应用程序中的数据记录。 这可能会变得复杂,因此最好的方式仍然让身份提供者将旧用户名传递给旧应用程序,直到旧系统被替换。

账号绑定

一个常见的要求,特别是在面向消费者的环境中,是允许用户注册应用程序帐户,输入应用程序所需的用户配置文件信息,然后再增加允许用户添加社交身份提供商登录其本地帐户的能力。这一要求的产生有几个原因,包括:
  • 应用程序有一个遗留的身份数据存储,但希望为用户提供通过remoteidentity提供者(通常是社交身份提供者)登录的便利。
  • 用户希望试用新的应用程序,而不授予该应用程序在社交身份提供商处访问其个人资料的权限。如果用户喜欢该应用程序,则稍后会希望利用其社交身份提供商帐户登录该应用程序。
应用程序通常希望消除尽可能多的使用障碍。允许用户通过远程身份提供程序登录意味着用户可以使用他们可能经常使用的凭据登录,并且比特定于应用程序的凭据更容易记住。此外,如果用户在访问应用程序时具有与身份提供者的现有认证会话,则用户可以通过单点登录直接进入应用程序,以获得更大的便利。
帐户链接可用于将远程帐户链接到本地应用程序帐户。链接很有用,因为帐户与特定上下文相关联。例如,具有标识符“[email protected]”的本地应用程序帐户与使用相同标识符的远程身份提供商的帐户是不同的帐户。如果用户使用标识符“[email protected]”注册应用程序帐户,然后使用注册时指定的标识符和凭据登录,则她将访问因注册而创建的本地应用程序帐户。但是,如果 yy然后通过社交身份提供商登录应用程序,该应用程序将收到一个安全令牌,其中包含有关 yy的各种声明。声明可能包括特定于该提供商的内部标识符和关于他的电子邮件地址的声明。但是,yy可能在社交提供商处使用了不同的标识符或电子邮件地址。除非应用程序能够将社交提供商帐户属性与用户的本地帐户相关联,否则用户在通过社交提供商登录时将无法访问其现有应用程序帐户。应用程序仅根据匹配的属性在帐户之间建立自动关联是有风险的,因为远程帐户可能没有经过验证的用户配置文件数据。因此,最好使用如下流程明确建立帐户之间的任何链接,该过程要求用户对两个帐户进行身份验证以证明它们的所有权。
  • 用户登录本地应用程序帐户,证明该帐户的所有权。
  • 本地应用程序提供支持链接的远程身份提供商列表。
  • 用户为要关联的第二个帐户选择远程身份提供商,例如社交提供商。
  • 应用程序向远程身份提供商触发身份验证请求以对用户进行身份验证。
  • 用户向远程身份提供商进行身份验证,证明其帐户在提供商处的所有权。
  • 应用程序从远程身份提供商处收到一个安全令牌,其中包含有关用户的声明。
  • 应用程序将远程帐户的标识符与用户的本地帐户相关联。
  • 当用户进行身份验证时,应用程序会搜索用户个人资料中的主要帐户标识符和任何辅助链接标识符,以查找用户的帐户。
在此示例中,链接的步骤建立了用户社交身份帐户与其应用程序的本地帐户之间链接。用户必须对两个帐户进行身份验证以证明它们的所有权,并在远程身份提供者处向应用程序提供用户标识符。对要关联的帐户的身份验证可以按任何顺序进行,但必须这样做,以防止通过帐户关联来接管帐户的风险。需要注意的是,在没有明确的双重身份验证步骤的情况下,应避免自动链接具有相同配置文件属性(例如电子邮件地址)值的帐户,以防止未经授权的帐户接管的可能性。如果在具有未经验证的属性(例如电子邮件地址)的帐户之间进行自动帐户链接,则可能会错误地链接属于不同人的帐户。最后,如果实现了帐户链接,用户应该可以取消他们之前链接的帐户的链接,以防用户出于某种原因希望停止使用已链接的帐户。如果实施得当,帐户关联可以方便用户通过不同的身份提供商登录并仍然访问同一帐户。

渐进式画像

渐进式画像可用于避免必须一次从用户那里收集大量信息。 用户可以用最少的信息注册一个应用程序帐户,然后逐步分析可以随着时间的推移添加到该数据中。 附加配置文件属性的收集可以在应用程序的后续使用或特定类型的事务需要时完成。 用户甚至可以使用远程身份提供商登录应用程序,并且应用程序可以使用来自远程提供商的信息为他们创建本地帐户。 在将用户重定向到该身份提供商之前或之后,系统会提示用户提供其他配置文件属性,并将来自这两个来源的信息合并到用户的本地应用程序配置文件中。

扮演

扮演被定义为一个人能够像另一个人一样登录应用程序并以该人的身份执行任何任务的能力。最常见的用例是支持人员需要以其他用户身份登录应用程序并查看用户体验以解决问题。不幸的是,这样的功能有可能被滥用,并且在现有应用程序中改装安全、受限的模拟功能可能是一项挑战。为了降低冒充者未经授权活动的风险,可以创建一个单独的故障排除应用程序,限制对故障排除所需的访问。例如,它可以提供对客户帐户配置和数据的查看访问权限,以便进行故障排除,但不能提供修改客户数据的能力。应用程序应记录所有活动,并应实施对异常活动日志的自动监控。理想情况下,在故障排除应用程序允许访问帐户之前,应获得帐户所有者的同意。不用说,故障排除应用程序应该受到足够的安全措施的保护,并且只授予授权人员,并经常审查授权用户列表。这种方法可以降低未经授权的内幕活动的风险。

委托

当一个用户需要授予另一个用户代表其行事的能力,以完成任务或数据的特定子集时,被称为委托。例如,一位忙碌的高管可能会将一些杂务委托给助理。助理有权代表他或她执行任务。另一种情况是,员工外出度假时需要将其任务(如支持票)的所有权委托给另一个人。在这两种情况下,都需要授予一个用户代表另一个用户执行特定操作的权限。此类功能最好设计在应用程序中,因为授权权限的授予是特定于应用程序的。例如,执行官可能希望将批准费用报告的能力委托给助理,但仅限于一定数额。应用程序日志记录应具有委托识别能力,以便记录被委托人完成的所有活动,并显示所涉及的委托和委托身份,以便进行完整的审核跟踪。委托的任务特定性质和对审核日志记录的需求使其最好在应用程序本身中实现。

环境

最后需要关注的是和环境相关的一些用例。

公用的工作环境

在某些环境中,用户需要登录共享的工作站。这种环境提供了许多用户使用的共享设备。比如在制造车间、医院和营业厅系统中找到。对于多人使用同一设备,让每个用户在开始会话时登录并在完成任务后注销会话非常重要。让用户在会话开始时登录很容易,但确保用户注销更具挑战性,因为用户可能会分心并在走开之前忘记注销。在短时间不活动后实施会话超时可以帮助保护用户。银行 ATM 机提供了一个很好的例子,在每次交易后询问用户是否需要继续其他交易,如果在短时间内没有响应,则会话立即终止。对于在浏览器中运行的应用程序,使用支持临时会话的浏览器,并设置浏览器策略以强制临时会话,以便清除以前用户会话中的信息是很有帮助的。如果您的应用程序可以在共享设备上使用,那么重要的是要考虑信息是否可以通过其他方式泄漏,例如临时文件,并降低发现的任何风险。这些步骤可以防止用户会话和数据在共享设备上受到损害。

身份提供者发现

对于面向员工的环境,通常有一个身份提供者来验证所有用户。在其他场景中,例如许多企业使用的多租户应用程序,每个企业可能都配置了自己的身份提供程序,并且应用程序可能需要为需要登录的用户确定适当的身份提供程序。这被称为身份提供者发现或主领域发现。当存在多个可能的身份提供者时,识别每个用户使用哪些身份提供者的机制包括:
  • 用户从列表中选择适当的身份提供者。
  • 用户输入信息,并执行查找以确定正确的身份提供者。
  • 从环境因素(如原始应用程序或域)派生身份提供者。
  • 从浏览器cookie 中的信息中获取身份提供者(如果可用),如果没有,则恢复到先前的方法之一。
如果应用程序配置了多个身份提供者用于对用户进行身份验证,这些选项可以帮助确定用户的正确身份提供者。

多租户应用

多租户应用程序通过应用程序的单个运行实例为多个租户提供服务,其中租户是一组相关用户,共享对应用程序管理的一组资源的访问权限。 虽然多租户应用程序本身很常见,但它们带来了一些与身份管理相关的独特挑战。 用户通常被授权访问特定租户。 如果给定用户被授权访问多个租户,则可以通过以下机制确定适当的租户:
  • 要求用户为每个租户使用不同的身份
  • 在登录前或登录后提供租户选择机制
第一个选项对用户来说可能不是很方便。 第二个选项通常是通过在用户访问应用程序的 URL 中包含租户名称或为用户提供租户选择机制来实现的。
除了将用户路由到特定租户之外,还可能需要跨租户启用不同的身份验证策略。对于面向业务的应用程序,可能需要允许每个租户的管理员配置不同的与身份相关的首选项,例如密码强度要求、用于验证用户身份的身份提供商,或者允许的单次登录会话长度。还可能需要支持客户检索日志数据的能力,但仅限于其租户。简言之,多租户应用程序必须满足所有通常的身份相关要求,但可能必须为每个租户提供拥有自己的身份相关配置设置的能力。

总结

本章介绍了几个可能适用于您的环境的不太常见的用例,以帮助您在项目早期识别此类需求。
  • 应用程序可能需要适应家庭关系、临时帐户、更改状态的用户以及可能需要解除身份认证的用户。
  • 在某些情况下,用户可能没有电子邮件帐户。
  • 在公司合并期间合并身份存储库可能需要更改用户名,并支持遗留应用程序对旧用户名的需求。
  • 帐户链接允许用户将多个远程身份链接到一个本地帐户,并通过其中任何一个帐户的身份验证以使用该帐户。
  • 渐进式评测使应用程序能够随着时间的推移建立用户配置文件。
  • 出于支持目的的模拟有可能被滥用,这可以通过定制的故障排除应用程序加以缓解。
  • 如果应用程序支持多个身份提供程序,则需要一种发现机制来确定每个用户使用的正确身份提供程序。