在使用 ACS(以及一般的声明)时,您应该注意一件事 - 您应该了解Claims。
现在,针对 ACS 特定问题。 Windows Azure 访问控制服务不是自动执行您想要的操作的魔杖。 ACS 是处理声明的最简单方法,并且只处理一组特定声明,并且不必为不同协议的所有不同实现而烦恼。实际上,在创建基于浏览器的应用程序时,您使用的是 WS-Federation protocol(默认情况下是 SAML token,但您也可以使用 SWT 令牌),而不是 OAuth 协议。当有人使用 ACS 登录您的网站时,您获得的用户唯一性是以下两个因素的严格组合:
你得到的唯一性是NameIdentifier claim(表示为:http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier)。
第一个问题是,假设我是“john.doe@gmail.com”,通过http://yourcompany.accesscontrol.windows.net 识别到您的网站,您将获得名称标识符“X”。当我通过http://yourcompany-live.accesscontrol.windows.net/ 向您的网站表明自己的“john.doe@gmail.com”时,您将获得名称标识符“Y”!这适用于所有身份提供者,您通过访问控制服务进行链接。
第二个问题是:通过 ACS 配置 Live ID 身份提供程序时,只会给您一个 NameIdentifier 声明。仅此而已。
现在回答问题:
问题1:如何连接?
链接身份的唯一可行方法是在您的应用程序中构建您自己的链接逻辑。我要做的是停止使用所有自动生成的代码和被动重定向到 ACS,而是手动处理一些被动联合。这意味着 - 我会注意用户是否登录。如果未登录,我会将用户重定向到我自己的自定义登录页面,我将从 ACS 获取配置的登录选项。当用户登录时,我将在我自己的用户数据库中为该用户创建一个条目。我将为我想链接到单个用户的所有可能的身份提供者提供字段(或链接表)。了解,我将存储用户可能拥有的所有 NameIdentifiers。现在,我将如何链接用户帐户。可能有不同的方法。首先,您必须识别用户以允许他/她链接帐户。然后创建一个带有一些唯一 ID(不是 GUID,以便用户轻松记住)的“联动票证”。向用户显示此 ID,并为他提供使用其他提供商登录的选项(从 ACS 检索 privers 列表)。当用户与另一个提供商一起来时 - 显示可以输入票证的字段。检查票证,如果有效 - 链接到现有帐户。
问题2:如何在系统中识别?
如答案一所述 - 您将需要拥有自己的自定义用户数据库,其中每个用户将拥有一个帐户,但该帐户将保存由不同机构发布的所有 NameIdentifier 声明。因此,您将能够唯一地识别具有关联帐户的用户。
问题3:如何赋予角色?不是从 azure 管理页面提供,而是
通过代码
在您的架构中,维护 ACS 中的角色将非常困难,因为您在需要链接多个帐户时输入的复杂性。我建议您在应用程序数据库中保留用户角色分配。您拥有本地用户帐户的部分,您将为每个帐户分配角色。
注意,当我说本地用户帐户时,我并不是说支持本地登录凭据,而只是支持用户配置文件!