金石推荐 | 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下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术语。我们将在稍后讨论这些技术细节,但在规划阶段理解高级概念是很重要的。

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

参考资源

相关文章
|
2天前
|
SpringCloudAlibaba Dubbo 应用服务中间件
【微服务】微服务初步认识 - 微服务技术如何学习 · 认识微服务架构
【微服务】微服务初步认识 - 微服务技术如何学习 · 认识微服务架构
12 0
|
2天前
|
存储 设计模式 架构师
编码之道:从技术细节到系统架构的升华
【5月更文挑战第9天】 在编程的世界里,每一行代码都承载着功能与美学的双重使命。本文将探讨如何从关注技术细节出发,逐步深化对系统架构的理解,并在实践中实现从代码编写者到系统设计师的转变。通过分析具体案例,我们将揭示那些看似平凡的技术感悟如何在复杂系统的构建中发挥关键作用,以及这一过程中对软件开发者的启示。
20 3
|
2天前
|
负载均衡 持续交付 API
构建高效微服务架构的五大关键技术
【5月更文挑战第13天】在当前软件开发领域,微服务架构已经成为一种流行趋势。本文将探讨构建高效微服务架构的五大关键技术,包括容器化部署、服务发现与注册、API网关、负载均衡以及持续集成与持续部署。这些技术可以帮助开发团队更快速、更可靠地构建和部署微服务应用,提高系统的可扩展性和可维护性。
|
2天前
|
传感器 存储 SQL
LabVIEW使用ModbusTCP协议构建分布式测量系统
LabVIEW使用ModbusTCP协议构建分布式测量系统
14 4
|
2天前
|
负载均衡 API 数据库
构建高效微服务架构的五大关键技术
【5月更文挑战第4天】 随着云计算和容器化技术的成熟,微服务架构已成为软件开发的主流模式。本文将详细探讨实现高效微服务架构的五个关键技术点:服务拆分策略、API网关设计、服务发现与注册、熔断机制以及分布式事务管理。这些技术点是确保微服务系统可扩展性、灵活性及稳定性的基石,对于后端开发者而言,掌握它们至关重要。文章将提供具体的实施建议和最佳实践,帮助读者构建和维护高性能的微服务系统。
|
2天前
|
监控 Java 开发者
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第13天】随着现代应用的复杂性日益增加,传统的单体应用架构已不足以满足快速迭代和可扩展性的需求。本文将探讨如何通过微服务架构来提升后端开发的效率和系统的可靠性,涵盖微服务设计原则、技术栈选择、部署策略以及维护实践。我们将分析微服务的优势与挑战,并提供一系列实施建议,帮助开发者在构建和维护分布式系统时做出明智决策。
|
2天前
|
存储 监控 API
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第13天】在现代软件开发中,随着业务需求的多样化和开发流程的复杂化,传统的单体应用架构逐渐显得笨重且难以适应快速变化。微服务架构作为一种新兴的分布式系统设计方式,以其灵活性、可扩展性和技术多样性受到广泛关注。本文旨在探讨微服务架构的核心概念、设计原则以及实施策略,为后端开发人员提供一种提升系统性能和开发效率的有效途径。
42 2
|
21小时前
|
敏捷开发 Kubernetes API
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第17天】 随着现代应用需求的多样化和复杂化,传统的单体应用架构逐渐显得笨重且难以适应快速变化。微服务架构应运而生,它通过将大型应用拆分为一系列小型、自治的服务来提供灵活性和可扩展性。本文将深入探讨微服务的概念,解析其核心组件,并展示如何利用现代后端技术栈构建和维护一个高效的微服务系统。我们将讨论微服务的优势,包括敏捷开发、独立部署、技术多样性以及弹性设计,并分析在实施过程中可能遇到的挑战,如服务发现、数据一致性和网络延迟问题。最后,我们将提供一个实际案例研究,以说明如何在现实世界中应用这些原则。
|
23小时前
|
Java API 开发者
构建高效的微服务架构:后端开发者的实用指南
【5月更文挑战第17天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代与灵活部署的需求。微服务架构作为解决这一问题的有效方案,已成为众多企业转型的首选架构模式。本文将深入探讨如何构建一个高效且可维护的微服务系统,涵盖关键设计原则、技术栈选择以及实践中的最佳实践。通过阅读本文,后端开发者将获得构建和优化微服务架构的核心知识,以支持业务的快速成长与创新。
|
1天前
|
设计模式 监控 安全
探索微服务架构下的服务网格
【5月更文挑战第16天】 随着现代软件系统向着复杂、动态和分布式的方向发展,传统的单体应用逐渐演变为更加灵活的微服务架构。在这一转变过程中,服务网格(Service Mesh)作为一种创新的基础设施层,正逐渐成为组织实现微服务治理的新宠。本文将探讨服务网格的基本概念、它在微服务架构中的作用以及它如何简化分布式系统的复杂性。通过对服务网格深入剖析,我们将了解其在提高系统可观测性、安全性及容错能力方面的独特价值,并探讨其对企业技术战略的影响。