选择 SP 发起或 IDP 发起的 SSO 的原因
Reasons to choose SP-Initiated or IDP-Initiated SSO
我对SP-init和IDP-init SSO的理解如下：
IDP-init SSO：IDP 生成 base64 编码的 saml 响应并发送给 SP，然后 SP 验证响应，最后如果响应有效则用户登录到应用程序。
SP-init SSO：一个saml请求从SP发送到IDP，然后IDP将验证用户然后发回saml响应，接下来的部分与IDP-init SSO相同。
我们如何决定SSO是使用SP-init还是IDP-init？由于身份验证部分，SP-init 似乎比 IDP-init SSO 更安全可靠。
SP初始化总是首选。 IDP-initilized 将使 SP 实现的工作更容易，但它会带来许多问题，例如 XSRF、互操作性和深度链接。
您根据用户期望或需要的导航流程进行选择（假设浏览器 POST 根据您的描述进行绑定）。
如果您的要求规定用户从安全（登录）网站 A 开始，然后在没有密码的情况下导航到网站 B，这根据定义是 IdP 发起的。
如果另一方面，如果用户预期在未经身份验证的站点上，但使用合作伙伴站点的凭据登录，这就是 SP 启动方案发挥作用的地方。如果您选择使用 Google 帐户登录（尽管使用了 SAML 的替代方法），Whosebug 本身会提供这种登录方式。用户从 Whosebug 上的某处开始，单击登录名 link，选择他们的 IdP（在 SAML 语义中）作为 Google，然后与身份验证请求一起发送到 IdP。在未指定类别的凭据质询之后（例如，您的浏览器可能已经在 IdP 站点进行了经过身份验证的会话，或者 IdP 可能使用双因素身份验证等），用户将返回到带有 SAML 响应文档的 SP 站点。
对我来说，服务商应用的业务需求告诉你：
如果与服务提供商的应用程序的所有用户交互都将从 "homepage" 或默认登录页面开始，那么 IdP 启动可能很有意义（不易中断 - 不需要签名的 AuthnRequest）。
如果有 "deeplinks" 通过电子邮件向您的用户提供报告之类的东西（也就是说，用户可以单击 link，这应该会让他们深入服务提供商的应用程序), 那么 SP 发起是唯一的出路。
在这两种情况下，用户都将根据 IdP 的身份验证规则在 IdP 处进行身份验证 - 在这方面，SP-init 或 IdP-init 都不是 "more secure"。流量：
IdP-init:
- 用户点击 link 启动 IdP-init SSO
- IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份验证
- IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
- SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序
SP-初始化：
- 用户点击link进入SP申请
- SP 应用程序确定用户没有令牌并重定向到 SP
- SP 重定向到 IdP
- IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份验证
- IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
- SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序
如您所见，唯一的区别是前三个步骤。
我对SP-init和IDP-init SSO的理解如下：
IDP-init SSO：IDP 生成 base64 编码的 saml 响应并发送给 SP，然后 SP 验证响应，最后如果响应有效则用户登录到应用程序。
SP-init SSO：一个saml请求从SP发送到IDP，然后IDP将验证用户然后发回saml响应，接下来的部分与IDP-init SSO相同。
我们如何决定SSO是使用SP-init还是IDP-init？由于身份验证部分，SP-init 似乎比 IDP-init SSO 更安全可靠。
SP初始化总是首选。 IDP-initilized 将使 SP 实现的工作更容易，但它会带来许多问题，例如 XSRF、互操作性和深度链接。
您根据用户期望或需要的导航流程进行选择（假设浏览器 POST 根据您的描述进行绑定）。
如果您的要求规定用户从安全（登录）网站 A 开始，然后在没有密码的情况下导航到网站 B，这根据定义是 IdP 发起的。
如果另一方面，如果用户预期在未经身份验证的站点上，但使用合作伙伴站点的凭据登录，这就是 SP 启动方案发挥作用的地方。如果您选择使用 Google 帐户登录（尽管使用了 SAML 的替代方法），Whosebug 本身会提供这种登录方式。用户从 Whosebug 上的某处开始，单击登录名 link，选择他们的 IdP（在 SAML 语义中）作为 Google，然后与身份验证请求一起发送到 IdP。在未指定类别的凭据质询之后（例如，您的浏览器可能已经在 IdP 站点进行了经过身份验证的会话，或者 IdP 可能使用双因素身份验证等），用户将返回到带有 SAML 响应文档的 SP 站点。
对我来说，服务商应用的业务需求告诉你：
如果与服务提供商的应用程序的所有用户交互都将从 "homepage" 或默认登录页面开始，那么 IdP 启动可能很有意义（不易中断 - 不需要签名的 AuthnRequest）。
如果有 "deeplinks" 通过电子邮件向您的用户提供报告之类的东西（也就是说，用户可以单击 link，这应该会让他们深入服务提供商的应用程序), 那么 SP 发起是唯一的出路。
在这两种情况下，用户都将根据 IdP 的身份验证规则在 IdP 处进行身份验证 - 在这方面，SP-init 或 IdP-init 都不是 "more secure"。流量：
IdP-init:
- 用户点击 link 启动 IdP-init SSO
- IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份验证
- IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
- SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序
SP-初始化：
- 用户点击link进入SP申请
- SP 应用程序确定用户没有令牌并重定向到 SP
- SP 重定向到 IdP
- IdP 验证用户是否已通过身份验证 - 如果未重定向以进行身份验证
- IdP 将身份验证属性（如用户名、电子邮件等）转换为 SAML 断言并将用户重定向到 SP
- SP 将 SAML 断言转换为 SP 应用程序令牌并重定向到应用程序
如您所见，唯一的区别是前三个步骤。