2

我正在尝试使用 Windows Azure 访问控制来避免在我的应用程序中使用用户名/密码的安全风险并简化身份验证。但是，这是一个可供希望“预认证”用户的中型或大型公司使用的站点。换句话说，他们可能希望通过输入用户的 Windows Live ID 来批量创建用户，并在该用户通过 Azure ACS 登录之前自动创建他们的帐户。我可以通过向该用户发送一封电子邮件来完成此操作，其中包含指向一次性使用页面的链接以创建他们的帐户，但我希望做一些更无缝的事情。

我正在尝试做的相当于 Team Foundation Service (*.visualstudio.com) 让您只需输入他们的 Windows Live ID 即可将用户添加到团队项目，一旦您这样做，他们就可以登录并访问该项目，即使该用户以前从未登录过 TFS。

我不明白的是如何使用 ACS 和 System.IdentityModel 来做到这一点。我可以使用 nameidentifier 声明来唯一标识一个用户，但是如何通过给定的提供程序为另一个用户获取 nameidentifier？

如果我没有很好地解释这一点，我很抱歉，所以请随时提出问题。

4

1 回答 1

2

不是真正的答案，只是想分享我对这个问题的看法。

ACS 和 Windows Live 身份验证的问题在于 ACS 从不返回用户的电子邮件地址。我们从 ACS 得到的只是一个告诉我用户已通过身份验证的令牌。此令牌是根据您的 ACS 领域创建的（即，如果您更改 ACS 领域，ACS 将为同一用户创建一个新令牌）。同样，使用您的应用程序的公司管理员可以输入用户的电子邮件地址，但无法从 ACS 取回该电子邮件地址。

只是大声思考:)，您可以做一些事情：

  1. 您使用 ACS 对用户进行身份验证，然后使用 Windows Live REST API 使用 ACS 发送的令牌获取有关用户的更多详细信息。通过使用 Windows Live REST API，您可以获得有关用户的更多详细信息，例如姓名、电子邮件地址等。或者，您可以只使用 Windows Live API 来验证用户。我不是 100% 确定，但我认为这就是 Team Foundation Service 所做的。请查看http://zud.io，因为它使用 Windows Live API。
  2. Another idea would be to create some sort of invitation tokens. In this approach, admins would "invite" folks. They would create invitation record by providing the name, email address of the users and the application would create unique invitation tokens. The application could then create an invitation link using which users would come to your application and authenticate themselves. Once authentication is done, you could look up the invitation record and retrieve user information from the database and create user record and associate the authentication token with the user record. The issue with this approach is that a user may not use the same Live Id as provided by the administrator. For example, I have at least 3 live ids and if I have that invitation link, I could sign with any of those live ids and the application won't be able to stop me from registering.
  3. Yet another idea would be to use Windows Azure Active Directory (WAAD) instead of ACS. You could consume Graph API in your application to create new users for your clients. You're still not managing user names and passwords as that is done by WAAD. The two issues I could think of there are - a) As an end user, I have to remember one more username/password combination and b) At the time of login, I have to provide my credentials in myusername@yourtenantname.onmicrosoft.com which to me personally is a big hassle.

We too have been going through the same pain and for now we have decided to go with approach #2.

Hope this helps.

于 2013-09-07T04:24:21.297 回答