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中包含域信息(例如，使用domain1.example.com或https://www.exampl…
了解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重定向。通常，管理员使用用户名和密码登录并进行必要的更改以解决问题。
