【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式

这篇具有很好参考价值的文章主要介绍了【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下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协议的运作机制和流程模式

现在我们准备介绍一些常见的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元数据(证书、端点等)。

【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
如果您是构建企业SaaS产品的独立软件供应商(ISV)，或者您正在为客户和合作伙伴构建面向外部的网站/门户/社区，则需要考虑支持多个IdP。这是许多需要与客户的企业身份基础设施集成的SaaS ISV的典型用例。根据应用程序的体系结构，您需要考虑如何存储来自每个身份提供者的SAML配置(例如，证书或IdP登录URL)，以及如何为每个提供者提供必要的SP信息。
【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式
一个关键注意事项涉及发布SAML响应的SP端的ACS URL端点。即使在处理多个IdP时，也可以公开单个端点。对于没有在URL中定义租用的单实例多租户应用程序(例如使用子域时)，这可能是一种更简单的实现方式。但是，您必须依靠SAML响应中的其他信息来确定哪个IdP正在尝试进行身份验证(例如，使用IssuerID)。如果您的应用程序是以多租户方式设置的，并且在URL中包含域信息(例如，使用https://domain1.example.com或https://www.example.com/domain1)，)，则每个子域都有一个ACSURL端点可能是个不错的选择，因为URL本身可以标识该域。
【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式

了解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值并将经过身份验证的用户带到正确的资源。
【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式

暴露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重定向。通常，管理员使用用户名和密码登录并进行必要的更改以解决问题。

参考资源

Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0
Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 文章来源地址https://www.toymoban.com/news/detail-449040.html

到了这里，关于【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！