将Azure ACS名称标识符从Live ID与已知用户列表相匹配？

Question

从仅在stackoverflow上发布的问题来看，Azure ACS似乎令许多实施者失望，因为它无法为Windows Live ID用户提供电子邮件地址。这不仅有助于注册新成员，而且还可以对返回成员进行身份验证。如果没有一些明确的流程可以实现后一个目的，即成员将身份提供者凭据连接到他们的帐户？

ACS确实为Live ID用户提供的“nameidentifier”声明是否可能与注册会员的正确编码的电子邮件地址相匹配？这是我设想的过程：

1. 访客在依赖方网站上注册，无需通过ACS进行身份验证。存储成员记录，包括恰好也在Live ID中注册的电子邮件地址。
2. 网站哈希使用特定于Live ID的哈希函数提供电子邮件地址，并存储除原始地址之外的用户可能使用Live ID进行身份验证的机会。
3. 成员返回时没有识别cookie，并选择通过ACS对Live ID凭证进行身份验证。
4. ACS返回Live ID的nameidentifier声明。
5. 网站将nameidentifier与步骤2中的哈希地址进行匹配。
6. 网站登录会员。

有谁知道这样的哈希函数是否可以公开？

干杯

BillVo

Answer 1

我不认为这是可能的。名称标识符因ACS名称空间而异。这是一个有意的设计选择，以防止多个网站合作（串通）和跟踪用户。您无法生成符合nameidentifer声明的LiveID哈希（如果我理解您的建议）。如果我可以预测它会是什么，它会使nameidentifier变得毫无用处。具体来说，我可以通过预测我想要串通的所有潜在网站来“反转”哈希，我们可以分享这些信息，使存在的原因没有实际意义。

对于LiveID，可以很容易地将ACS登录与用户配置文件相关联：您首先通过ACS登录，然后在您的站点上注册。此时，您将本地配置文件或ACS中的规则存储在用户的电子邮件地址中。我更喜欢前者（即如果我看到名称标识符X，我在我的数据源中查找配置文件并知道用户的电子邮件地址）。但是，在ACS中设置一个规则来获取X名称标识符的传入声明并产生用户提供的电子邮件地址的传出声明并非不可能。这样做的缺点是你在ACS中提供了大量的规则来容纳它。

Answer 2

dunnry说的一切！

严重的是 - 我认为Live ID在这里做对了 - 当用户提供Live ID（注册）的详细信息时，它不同意与其他任何人分享这些信息，并且分享这些信息不应该是使用任何网站/应用程序的先决条件。

ACS和Live ID为您提供了重复唯一标识用户的机制，然后您应该询问用户您需要的任何其他详细信息并自行存储。

例如，谷歌在没有理由的情况下，将向用户的名字和电子邮件分享一步。我写过关于here

的文章

Answer 3

您需要使用Windows Live SDK来提取用户个人资料。