【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下 Saml 协议的运作机制和流程模式
Saml 协议
传统上，企业应用程序在公司网络中部署和运行。为了获取有关用户的信息，如用户配置文件和组信息，这些应用程序中的许多都是为与公司目录(如 Microsoft Active Directory)集成而构建的。更重要的是，通常使用目录存储和验证用户的凭据。例如，如果您使用在本地运行的 SharePoint 和 Exchange，则您的登录凭据就是您的 Active Directory 凭据。
然而，随着协作的增加和向基于云的环境的转变，许多应用程序已经超越了公司领域的边界。联合身份验证是这个问题的解决方案。
想要了解 Saml 协议，可以参考对应的官方文档。
认证服务
大多数应用程序都有一个用户存储(数据库或 LDAP)，其中包含用户配置文件信息和凭据等。当用户登录时，凭据将根据此用户存储进行验证。这种简单方法的优势在于，所有内容都在应用程序中进行管理，从而提供了一种对最终用户进行身份验证的单一且一致的方法。但是，如果用户需要访问多个应用程序，其中每个应用程序都需要不同的凭据集，那么最终用户就会遇到问题。首先，除了可能已经存在的任何其他公司密码(例如，他们的 AD 密码)之外，用户还需要记住不同的密码。用户现在被迫维护单独的用户名和密码，并且必须处理不同的密码策略和过期时间。此外，当应用程序用户继续可以访问本应被撤销的应用程序时，这种情况还会让管理员和 ISV 感到头疼。
联合身份
联合身份始于需要支持跨越公司或组织边界的应用程序访问。想象一下，一家果汁公司(JuiceCo)将其产品销售给一家大型连锁超市(BigMart)之间的关系。作为 JuiceCo 的一名员工，您需要访问 BigMart 提供的应用程序来管理关系并监控供应和销售。在这种情况下，BigMart(提供该应用程序)将需要负责用户身份验证。简单的方法是要求在 JuiceCo 工作的用户使用不同的用户名和密码。但是，考虑一下该应用程序需要维护的所有用户--包括需要访问该应用程序的所有其他供应商及其用户。解决这一问题的一个更好的方法是允许 JuiceCo 和其他所有供应商共享或联合 BigMart 的身份。作为 JuiceCo 的一名员工，您已经拥有企业身份和凭据。联合身份为连锁超市(服务提供商)提供了一种安全的方式，通过与其供应商(身份提供商)现有的身份基础设施集成来外部化身份验证。
这种用例导致了联邦协议的诞生，例如：Security Assertion Markup Language (SAML) (opens new window).
SAML 的规划
SAML 主要用作基于 Web 的身份验证机制，因为它依赖于使用浏览器代理来代理身份验证流。在较高级别，SAML 的身份验证流如下所示：
现在我们准备介绍一些常见的 SAML 术语。我们将在稍后讨论这些技术细节，但在规划阶段理解高级概念是很重要的。
SP
服务提供商(SP)是提供服务的实体，通常以应用程序的形式提供。
IdP
身份提供者(IdP)是提供身份的实体，包括对用户进行身份验证的能力。身份提供者通常还包含用户配置文件：有关用户的其他信息，如名字、姓氏、工作代码、电话号码、地址等。根据应用程序的不同，一些服务提供商可能需要非常简单的配置文件(用户名、电子邮件)，而其他服务提供商可能需要更丰富的用户数据集(工作代码、部门、地址、位置、经理等)。
SAML 请求
SAML 请求，也称为身份验证请求，由服务提供商生成以“请求”身份验证。
SAML 响应
SAML 响应由身份提供者生成。它包含经过身份验证的用户的实际断言。此外，SAML 响应可能包含其他信息，例如，用户配置文件信息和组/角色信息，具体取决于服务提供商可以支持的内容。
服务提供商启动(SP 启动)
登录描述由服务提供商启动时的 SAML 登录流程。这通常在最终用户尝试访问资源或直接在服务提供商端登录时触发。例如，当浏览器尝试访问服务提供商端受保护的资源时。
身份提供者启动(IdP 启动)
身份提供者启动(IdP 启动)登录描述由身份提供者启动的 SAML 登录流。在该流程中，身份提供商发起 SAML 响应，该响应被重定向到服务提供商以断言用户的身份，而不是由来自服务提供商的重定向触发 SAML 流。
需要注意的几个关键事项
服务提供商从不与身份提供商直接交互。
浏览器充当执行所有重定向的代理。
服务提供商需要知道要重定向到哪个身份提供商，然后才能知道用户是谁。
在身份提供者返回 SAML 断言之前，服务提供者不知道用户是谁。
此流程不一定要从服务提供商开始。
身份提供者可以发起身份验证流。
SAML 身份验证流是异步的。
服务提供商不知道身份提供商是否会完成整个流程。
因此，服务提供商不维护所生成的任何身份验证请求的任何状态。当服务提供商收到来自身份提供商的响应时，该响应必须包含所有必要的信息。
规划核对表
虽然 SAML 协议是一个标准，但根据您的应用程序的性质，有不同的方法来实现它。下面是一个核对表，将指导你完成一些关键的考虑事项。
了解服务提供商的角色。
单一身份识别方案与多个身份识别方案。
了解 SP 发起的登录流。
暴露 SP 中的 SAML 配置。
为每个人启用 SAML，而不是为部分用户。
实施“后门”
了解服务提供商的角色
SAML IdP 根据 IdP 和 SP 共同同意的配置生成 SAML 响应。在收到 SAML 断言后，SP 需要验证断言是否来自有效的 IdP，然后解析断言中的必要信息：用户名、属性等
要执行此操作，SP 至少需要以下各项：
证书-SP 需要从 IdP 获取公共证书以验证签名。证书存储在 SP 端，并在 SAML 响应到达时使用。
ACS Endpoint-断言消费者服务 URL-通常简称为 SP 登录 URL。这是由发布 SAML 响应的 SP 提供的终结点。SP 需要将此信息提供给 IdP。
IdP 登录 URL-这是发布 SAML 请求的 IdP 端的终结点，SP 需要从 IdP 获取此信息。
实现 SAML 的最简单方法是利用开源 SAML 工具包。这些工具包提供了消化传入 SAML 响应中的信息所需的逻辑。此外，如果 SP 需要支持 SP 发起的登录流，工具包还提供生成适当的 SAML 身份验证请求所需的逻辑。
单一身份识别方案与多个身份识别方案
如果您正在构建内部集成，并且希望启用 SAML 以将其与您的公司 SAML 身份提供程序集成，那么您将考虑仅支持单个 IdP。在这种情况下，您的集成只需要处理一组 IDP 元数据(证书、端点等)。
如果您是构建企业 SaaS 产品的独立软件供应商(ISV)，或者您正在为客户和合作伙伴构建面向外部的网站/门户/社区，则需要考虑支持多个 IdP。这是许多需要与客户的企业身份基础设施集成的 SaaS ISV 的典型用例。根据应用程序的体系结构，您需要考虑如何存储来自每个身份提供者的 SAML 配置(例如，证书或 IdP 登录 URL)，以及如何为每个提供者提供必要的 SP 信息。
一个关键注意事项涉及发布 SAML 响应的 SP 端的 ACS URL 端点。即使在处理多个 IdP 时，也可以公开单个端点。对于没有在 URL 中定义租用的单实例多租户应用程序(例如使用子域时)，这可能是一种更简单的实现方式。但是，您必须依靠 SAML 响应中的其他信息来确定哪个 IdP 正在尝试进行身份验证(例如，使用 IssuerID)。如果您的应用程序是以多租户方式设置的，并且在 URL 中包含域信息(例如，使用https://domain1.example.com或https://www.example.com/domain1)，)，则每个子域都有一个 ACSURL 端点可能是个不错的选择，因为 URL 本身可以标识该域。
了解 SP 发起的登录流
如前所述，IdP 发起的登录流从 IdP 开始。由于它从 IdP 端开始，因此除了用户尝试通过身份验证并访问 SP 这一事实外，没有关于用户尝试在 SP 端访问的其他上下文。通常，在用户通过身份验证后，浏览器将转到 SP 中的通用登录页。
在 SP 发起的流中，用户尝试直接在 SP 端访问受保护的资源，而 IdP 不知道该尝试。出现了两个问题。首先，如果需要对联合身份进行身份验证，则需要识别正确的 IdP。使用 SP 启动的登录时，SP 最初对身份一无所知。作为开发人员，您需要弄清楚 SP 如何确定应该由哪个 IdP 接收 SAML 请求。在某些情况下，如果您的应用程序 URL 包含映射到唯一租户和 IdP 的子域信息，则命中的资源链接足以识别 IdP。如果不是这样，则可能需要提示最终用户提供来自最终用户的其他信息，如用户 ID、电子邮件或公司 ID。您需要一些允许 SP 识别尝试访问资源的用户属于哪个 IdP 的内容。请记住，您只是提示输入一个标识符，而不是凭据。Okta 还支持通过 LoginHint 参数将标识传递给 IdP，这样用户在重定向到 IdP 登录时，就不需要再次输入该标识。有关触发 OKTA 将“LoginHint”发送到 IdP 的说明，请参阅使用 SAML 深度链接重定向。
SP 发起的登录流的另一个问题是对深度链接的支持。大多数应用程序都支持深度链接。例如，您可能会收到一个指向驻留在内容管理系统上的文档的链接。理想情况下，如果您需要在访问文档之前进行身份验证，则希望在身份验证后立即访问该文档。
SAML 是一种专门设计的异步协议。SP 发起的登录流程从生成 SAML 身份验证请求开始，该请求被重定向到 IdP。此时，SP 不存储有关该请求的任何信息。当 SAML 响应从 IdP 返回时，SP 将不知道任何有关触发身份验证请求的初始深层链接的信息。幸运的是，SAML 通过一个名为 RelayState 的参数支持这一点。
RelayState
RelayState 是一个可以作为 SAML 请求和 SAML 响应的一部分包括的 HTTP 参数。在 SP 发起的登录流程中，SP 可以使用有关请求的附加信息设置 SAML 请求中的 RelayState 参数。SAML IdP 在收到 SAML 请求后，获取 RelayState 值，并在用户通过身份验证后将其作为 HTTP 参数附加回 SAML 响应中。这样，当往返完成时，SP 可以使用 RelayState 信息来获取有关初始 SAML 身份验证请求的其他上下文。
在深度链接的情况下，SP 使用深度链接值设置 SAML 请求的 RelayState。当 SAML 响应返回时，SP 可以使用 RelayState 值并将经过身份验证的用户带到正确的资源。
暴露 SP 中的 SAML 配置
如前所述，SP 需要 IdP 配置来完成 SAML 设置。虽然许多 ISV 选择通过支持和电子邮件来实现这一点，但更好的方法是向客户的 IT 管理员显示自助服务管理员页面，以启用 SAML。SAML 支持 IdP 端和 SP 端的元数据。在 SP 侧配置 IdP/SP 关系的一种方式是建立接收 IdP 元数据文件的能力和生成供 IdP 使用的 SP 元数据文件的能力。这是首选的方法。
然而，一些 ISV 选择允许直接配置几个关键的 SAML 参数，而不是通过元数据文件。典型参数包括 IdP 重定向 URL(用于 SAML 请求)、IssuerID、IdP 注销 URL。SP 还必须允许上载或保存 IdP 公共证书。
最好使用元数据文件，因为它可以处理 SAML 支持中未来的任何添加/增强，而无需进行用户界面更改(如果在用户界面中公开特定的 SAML 配置参数，则需要进行这些更改)。
为每个人启用 SAML，而不是为部分用户
根据应用程序的性质，可能有理由只允许部分用户启用 SAML。想象一下内部员工和外部用户(如合作伙伴)可以访问的应用程序。员工可以使用 SAML 登录到应用程序，而外部用户可以使用一组单独的凭据。
即使在目的是让特定租户的所有用户都启用 SAML 的情况下，在概念验证、测试和推出期间只启用部分用户，以便在对所有用户启用之前测试较小的用户子集的身份验证，也可能是有用的。
实施“后门”
如果您的应用程序中所有人都打算启用 SAML，这一点尤其重要。有时，SAML 配置中可能存在错误--或者 SAML IdP 端点中发生了一些变化。无论如何，你都不想被完全锁在门外。让管理员可以使用后门访问锁定的系统变得极其重要。这通常是通过拥有一个“秘密”登录 URL 来实现的，该 URL 在访问时不会触发 SAML 重定向。通常，管理员使用用户名和密码登录并进行必要的更改以解决问题。
参考资源
🏆 InfoQ写作平台-签约作者 🏆 2020-03-25 加入
【个人简介】酷爱计算机科学、醉心编程技术、喜爱健身运动、热衷悬疑推理的“极客达人” 【技术格言】任何足够先进的技术都与魔法无异 【技术范畴】Java领域、Spring生态、MySQL专项、微服务/分布式体系和算法设计等
评论