选择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

对我而言，服务提供商的应用程序的业务要求告诉您：

如果与服务提供商的应用程序进行的所有用户互动都将在＆＃34;主页＆＃34;或默认目标网页上启动，那么启动IdP可能会很有意义（减少打破 - 不会需要签名的AuthnRequest）。

如果有＆＃34;深层链接＆＃34;通过电子邮件向用户提供报告之类的内容（也就是说，用户可以点击应该在服务提供商的应用程序中深入了解的链接），然后SP发起是唯一的前进方式。 / p>

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

IDP-INIT：

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

SP-INIT：

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，并通过authn请求发送给IdP。在未指定排序的凭证质询（例如，您的浏览器可能已经在IdP站点上具有经过身份验证的会话，或者IdP可能使用双因素身份验证等）之后，用户将返回到具有SAML响应文档的SP站点。

Answer 3

SP初始化总是更喜欢。 IDP-initilized将使SP的实施更容易，但它带来了许多问题，如XSRF，互操作性和深层链接。