选择 SP-Initiated 或 IDP-Initiated SSO 的原因 [关闭]

Question

我对 SP-init 和 IDP-init SSO 的理解如下：

IDP-init SSO：IDP生成base64编码的saml响应并发送给SP，SP然后验证响应，如果响应有效，最终用户登录应用程序。

SP-init SSO：从SP 向IDP 发送一个saml 请求，然后IDP 将认证用户然后发回saml 响应，下一部分与IDP-init SSO 相同。

我们如何决定 SSO 是使用 SP-init 还是 IDP-init ？由于身份验证部分，SP-init 似乎比 IDP-init SSO 更安全可靠。

Answer 1

对我来说，服务提供商应用的业务需求告诉你：

如果与服务提供商的应用程序的所有用户交互都将从“主页”或默认登录页面开始，那么 IdP 启动可能很有意义（较少中断 - 不需要签名的 AuthnRequest）。

如果通过电子邮件向您的用户提供了诸如报告之类的“深层链接”（也就是说，用户可以单击一个链接，该链接应该将他们带入服务提供商的应用程序的深处），那么由 SP 发起的就是唯一的出路。

在这两种情况下，用户都将根据 IdP 的身份验证规则在 IdP 上进行身份验证 - 在这方面，SP-init 或 IdP-init 都不是“更安全”的。流程：

IdP 初始化：

1. 用户单击链接以启动 IdP-init SSO
2. IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份​​验证
3. IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
4. SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序

SP-初始化：

1. 用户点击链接进入 SP 应用程序
2. SP 应用程序确定用户没有令牌并重定向到 SP
3. SP 重定向到 IdP
4. IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份​​验证
5. IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
6. SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序

如您所见，唯一的区别是前三个步骤。

Answer 2

您根据用户所需或要求的导航流程进行选择（假设浏览器 POST 绑定基于您的描述）。

如果您的要求要求用户从安全（登录）网站 A 开始并在没有密码的情况下导航到网站 B，则根据定义，这是 IdP 发起的。

另一方面，如果用户希望在未经身份验证的站点上使用来自合作伙伴站点的凭据登录，这就是 SP 发起的场景发挥作用的地方。如果您选择使用 Google 帐户登录，StackOverflow 本身会提供这种登录方式（尽管使用了 SAML 的替代方法）。用户从 StackOverflow 上的某处开始，单击登录链接，将其 IdP（在 SAML 语义中）选择为 Google，并通过身份验证请求发送给 IdP。在未指定类型的凭证质询之后（例如，您的浏览器可能已经在 IdP 站点具有经过身份验证的会话，或者 IdP 可能使用双因素身份验证等），用户将返回到带有 SAML 响应文档的 SP 站点。

Answer 3

SP 初始化总是首选。 IDP-initilized 将使 SP 实现的工作更容易，但它带来了许多问题，例如 XSRF、互操作性和深度链接。