IDP-init SSO:IDP生成一个经过base64编码的SAML响应并发送给SP,SP验证响应,如果响应有效,则用户就会登录到应用程序。
SP-init SSO:SP向IDP发送SAML请求,然后IDP将验证用户,之后再发送SAML响应,接下来的步骤与IDP-init SSO相同。
我们如何决定选择使用SP-init还是IDP-init SSO?SP-init似乎比IDP-init SSO更安全可靠,因为它包含了身份验证部分。
对于服务提供商的应用程序,业务需求告诉你:
如果所有用户与服务提供商的应用程序的交互都将从“主页”或默认着陆页面开始,则 IdP-initiated 可能是很有意义的选择(更少出错 - 无需签名的 AuthnRequest)。
如果向您的用户提供了“深度链接”,如通过电子邮件提供的报告(即用户可以单击链接,以便在服务提供商的应用程序内部进行深入操作),那么 SP-initiated 是唯一的可行之路。
在两种情况下,用户都会根据 IdP 的身份验证规则在 IdP 上进行身份验证 - 在这方面,SP-init 或 IdP-init 都不“更安全”。具体流程如下:
IdP-init:
SP-Init:
如您所见,唯一的区别在于前三个步骤。
根据所需或必要的用户导航流程进行选择(假设基于您的描述,浏览器POST绑定)。
如果您的要求规定用户从安全(已登录)网站A开始,并在不使用密码的情况下导航到网站B,则这是定义上的IdP启动。
另一方面,如果预计用户将在未经身份验证的站点上,但使用来自合作伙伴站点的凭据进行登录,则SP启动场景就发挥作用了。 StackOverflow本身提供了这种登录方式,如果您选择使用Google帐户登录(虽然使用了SAML的替代方法)。用户在StackOverflow的某个位置开始,单击登录链接,选择其IdP(在SAML语义中)为Google,并随着一个authn请求被发送到IdP。在未指定类型的凭据挑战之后(例如,您的浏览器可能已经在IdP站点上具有已验证的会话,或者IdP可能使用两因素认证等),用户将返回到带有SAML响应文档的SP站点。
始终优先选择SP-initialized。IDP-initialized会使SP实现更加容易,但它带来了一系列问题,如XSRF、互操作性和深度链接。