网络osi七层模型_分布式微服务架构「建议收藏」

网络osi七层模型_分布式微服务架构「建议收藏」如果您的应用程序是以多租户方式设置的,并且在URL中包含域信息(例如,使用https://domain1.example.com或https://www.example.com/domain1),

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

参考资源

  • 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

今天的文章网络osi七层模型_分布式微服务架构「建议收藏」分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/82177.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注