2

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

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

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

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

干杯

比尔沃

4

3 回答 3

5

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

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

于 2011-12-14T17:20:30.737 回答
2

邓瑞所说的一切！

说真的 - 我认为 Live ID 在这里做了正确的事情 - 在用户向 Live ID（注册）提供详细信息时，它不同意与其他任何人共享此信息，并且共享此信息不应该是先决条件使用任何网站/应用程序。

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

例如，谷歌在没有理由这样做的情况下，正在进一步分享用户的姓名和电子邮件。我在这里写过这个

于 2011-12-14T20:31:48.423 回答
0

您需要使用Windows Live SDK来提取用户配置文件。

于 2012-09-07T19:32:50.250 回答