如何在基于SAML的SSO中支持多个用户群而不同步它们?

时间:2014-09-05 08:45:08

标签: single-sign-on saml-2.0 federation

我正在阅读基于SAML2.0的联合,因为它应该在当前设置中申请SSO:

  • 在应用 A 中,用户拥有凭据 email / password1
  • 在应用 B 中,同一用户拥有凭据 username / password2
  • 如果用户登录 A ,他/她也应该登录 B

在这种情况下,SAML v2.0似乎是一个不错的选择:

  • 中央身份提供商(IdP),可能 A B 或第三方 C
  • A B 将成为服务提供商(SP)
  • 如果用户尝试访问 A A 将从包含电子邮件的IdP请求SAML断言
  • 如果用户尝试访问 B B 将从包含用户名
  • 的IdP请求SAML断言
  • 但是如果用户在 A 中进行了身份验证,他/她应该如何登录 B 用户名)?

有关SAML的文档(例如此处:https://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf)假装SAML允许SSO而无需在所有播放器之间同步或迁移身份。

但是,我没有看到,如果不维护和合并中央IdP中同一主题的所有凭证,这实际上是一种同步,这一切是如何工作的。

如果您觉得我对SAML v2.0功能感到困惑,那么你是对的; - )

2 个答案:

答案 0 :(得分:3)

作为服务提供商,SAML通常不允许您取消用户商店。这是因为它是一种仅通过外部化身份验证的方法。大多数服务提供商在其商店中与用户身份提供商之间存在一对一的关系。但是,它可能不需要这样,因为您也可以执行一对多联合。我很快就会扩大。

在一对一中,您通常会使用"及时使用"配置方法,或带外用户同步方法。及时通常通过断言中提供的属性来完成,并且当它意识到在断言中呈现的用户不存在应用程序的用户存储时由SP完成。带外方法是一些其他过程,目录同步等。用户被添加到IdP的商店,并且一些过程通过平面文件,XML等将该用户添加到SP商店。

话虽如此,根据服务提供商的类型,您可以执行一对多,并仅依靠提供的属性来支持应用程序的需求。我们假设您正在进行打印操作。您可以同意让IdP发送成本中心以及用户的其他属性(姓名,号码,电子邮件等)。然后,所有数据都存储在该打印作业中,并在结算期间将成本中心发回。我会说,在我的职业生涯中,我只见过几个一对多联合会的例子。

我不认为你的榜样是对的 - 这意味着你并没有问得对,但是再一次,你可能不够熟悉,可能。

让我们假设以下内容:

  • 服务提供商X需要用户名
  • 服务提供商Y需要电子邮件
  • 身份提供商A可以从其用户商店
  • 提供所有这些内容

用户出现在SPX。 SPX根据你去过的网址(idpa.serviceproviderx.com)说,我知道你需要被发送到IdPA。"并将用户重定向到IdPA。 IdPA对用户进行身份验证,查看其属性合同"确定它应该向SPX发送用户名,并将具有该属性的用户重定向为" subject"在断言中。 SPX使用该断言,并可以将用户映射回他们应该去的地方。

现在,用户正在浏览其门户,并单击启动SSO到SPY的链接。用户已经通过IdPA身份验证,因此IdPA会检查其合同并发现它应该使用带有SPY的电子邮件。它以电子邮件为主题为SPY创建一个断言,并将用户重定向到SPY以消耗断言和连接到应用程序。

现在,在这两种情况下,IdP必须确定要发送什么来完成与SP的合同 - 而且它总是会。这是基于"合同" - IdP和SP之间的某种形式的协议,必须由两个系统的管理员支持。

答案 1 :(得分:0)

好的,我认为这里的主要误解是身份验证在SAML中的工作原理。我SAML IDP验证用户。这意味着,SP上没有凭证存储。

SAML中的SSO发生在IDP。如果用户已经在IDP登录过一次,则用户只是在没有进行身份验证的情况下被发送回SP。