0

我们必须为 SSO 集成第三方 SP。我们的应用程序是 spring（不是 springboot）中的一个包装器，它具有使用 mongo 作为 DB 调用后端服务的身份验证/授权模块。现在的要求是将基于 SSO SAML 的 SP 与第三方集成。第三方提供了要求拥有 IDP 的文档。在 SP 提供的要求中，Nameid 断言必须是持久的、唯一的和不透明的，并且可以是客户端应用程序（我们的应用程序）的用户 ID。我相信我们必须有一个像 SSOCircle 或 Okta 这样的 IDP 或一些开源 IDP 才能与 SP 集成。而且我认为我们可以编写一个单独的 springboot SAML IDP 并将 api 暴露给我们的旧 spring 以登录到 SP。据我了解流动：

  1. 来自我们门户的用户访问第三方 SP 网站或 API。
  2. 第三方 SP 会将用户重定向到我们的 IDP 以登录。他们将​​保存 NameId（用户 ID 或用户 ID 的 UUID 映射），并将其作为 SAML 请求与其他断言一起传递。
  3. 一旦用户成功登录，我们的 IDP 会将用户重定向到第三方 SP 并返回成功响应。

我的问题：

  1. 我们可以（或者我们应该）绕过 IDP 吗？我想这意味着我们自己编写 SAML IDP。请让我知道我的最佳选择，或者不使用 IDP 并编写我们自己的等效项是否是一个好主意。如果我们不能，我会假设我们已经购买了付费专有或使用开源 IDP。
  2. Nameid (unique, persistent, opaque) assertion ：这是SP要求之一。如果我们必须使用IDP（我认为），它SP消费者断言要求是使用持久Nameid来传递。它应该是唯一的，持久的和不透明的。所以我们认为 SAML 请求中用户 ID 到 IDP 的 UUID 映射应该没问题。如果我们这样做，我们必须将 UUID 映射作为 nameid assertion 存储在 DB 中。我们是否必须在 DP -SP 集成中仅使用我们的门户用户 ID 作为 nameIds 或 UUID 以满足要求？请评论哪种方法是正确的。
  3. IDP 端和 SP 端的 Nameid 持久性限制：我们端存在一个瓶颈。出于安全考虑，我们的 IT 安全团队可能不会永远允许 NameId 持久映射 UUID，在这种情况下，NameId 映射将在我们端发生变化。如果我们必须使用 UUID 作为 nameid，应该如何解决这个问题？
  4. NameId 配置：当用户从我们的门户请求登录到 SP - 它会作为登录请求传递给 SP，然后 SP 构造 saml 请求并将 nameids 断言传递给 IDP？如果是，将nameids作为登录请求传递给SP的最佳方法是什么？如果不是，SP 如何知道在 SAML 中将哪个 UUID 传递给 IDP？如果映射 nameid 是 UUID，由于安全问题可能会发生变化，我们将如何解决这个问题？. 另一件事是，虽然提到 nameid 在需求中被提及为“持久”，但在需求文档的示例中它们正在显示urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified。我认为这可能是文档中的一个错误。[?]。
  5. 我们可以参考的任何示例 SSO SAML IDP（客户端）应用程序接近上述 1）和 2）？
4

1 回答 1

0

我们可以（或者我们应该）绕过 IDP 吗？我想这意味着我们自己编写 SAML IDP。

不，你不能。如果第 3 方充当 SAML 服务提供者，您需要或充当 SAML 身份提供者。构建自己的实现是一项艰巨的任务，您可以使用基于 SAAS 的 IdP，如 SSO Cirle（请记住，您的客户需要接受用户身份数据的存储位置）或部署您自己的 SAML IdP。有付费产品/服务或免费。开源不一定意味着免费，这经常被误解。

如果您仍然需要 SAML IdP，您可能会考虑让自己的应用程序也充当 SAML SP，以利用 IdP 的身份验证。

使用哪种 NameId 格式是一种协议。SAML 规范建议为特定目的使用特定的 NameId 格式，例如

  • 'transient' NameId 格式仅用于 SSO 流。
  • 当您想将不同身份孤岛的身份链接在一起时，可以使用“持久”

SP 可以使用主题中 NameId 值的值来查找用户的配置文件或执行自动联合（在其一侧构建配置文件）。它还可以使用 SAML 属性语句中的属性来实现相同的目的。许多 SP 实现提供了这一点。

于 2020-10-21T06:50:12.430 回答