从仅关于stackoverflow此处发布的问题来看,由于Azure ACS无法为Windows Live ID用户提供电子邮件地址,因此它使许多实施者都感到失望。这不仅对注册新成员而且对返回成员进行身份验证当然都是有用的。也许如果没有将成员将身份提供者凭据连接到其帐户的任何明确过程,仍然可以实现后一个目的?

ACS确实为Live ID用户提供的“nameidentifier”声明是否可以与注册成员(member)的正确编码的电子邮件地址匹配?这是我设想的过程:

  • 访客在依赖方网站上注册,无需通过ACS进行身份验证。存储的成员记录包括一个电子邮件地址,该电子邮件地址恰好也已使用Live ID注册。
  • 网站哈希使用特定于Live ID的哈希函数提供了电子邮件地址,并在原始地址之外存储了该电子邮件地址,以免用户可能使用Live ID进行身份验证。
  • 成员返回时没有标识Cookie,并选择通过ACS使用Live ID凭据进行身份验证。
  • ACS返回Live ID的名称标识声明。
  • 网站将nameidentifier匹配到步骤2中的哈希地址。
  • 网站登录成员(member)。

  • 有谁知道这样的哈希函数是否可能公开可用?

    干杯

    比尔沃

    最佳答案

    我认为这是不可能的。每个ACS namespace 的名称标识符都不同。这是一个有意的设计选择,可防止多个网站进行协作(欺诈)和跟踪用户。您无法产生与nameidentifer声明匹配的LiveID哈希(如果我理解您的建议)。如果我可以预测的话,它将使nameidentifier变得毫无用处。具体来说,然后我可以通过预测要与之勾结的所有潜在网站来“反转”哈希,然后我们可以共享该信息,从而说明存在存在的理由。

    对于LiveID,将ACS登录名与用户配置文件关联起来很容易:首先让用户登录ACS,然后在您的站点上注册。那时,您将用户的电子邮件地址存储在本地配置文件或ACS中的规则中。我更喜欢前者(即,如果我看到名称标识符X,我会在数据源中查找个人资料并知道用户的电子邮件地址)。但是,并非不可能仅在ACS中提供一条规则,该规则接受X名称标识符的传入声明并产生用户提供的电子邮件地址的传出声明。不利的一面是,您可能在ACS中预配置大量规则以适应这种情况。

    10-05 22:17