我们正在从头开始构建一个在 Windows Azure 上运行的 ASP.NET MCV 3 应用程序。关于身份验证和授权层,我们正在考虑使用访问控制服务。我浏览了一些关于 ACS 的文章,在那里我得到了基本的想法,但我仍然对它有一些疑问。
我的理解是,使用 ACS 我们将身份验证过程外包给一个或多个身份提供者 (IP),基本上我们信任另一个系统(即 Microsoft Live ID)来验证我们的用户。
基本过程非常简单:在身份验证阶段,我们将用户重定向(ACS 执行此操作)到我们的“受信任”IP 之一,这会将用户(使用有效令牌)重定向到 ACS 并最终重定向到我们的应用程序。
这里有几个问题:
由于我们不希望所有拥有 Live ID 帐户的用户都可以访问我们的应用程序,因此我认为应该有另一个流程来验证该用户并检查他是否已在我们的应用程序中注册。问题是在哪里?在 ACS 中还是在我们的应用程序中?
我对此有一个想法,但我不知道这是否是正确的方法:
在注册阶段,系统(我们的网络应用程序。)询问用户他想使用哪个 IP(即 Live ID、Google、Facebook 和我们的应用程序)在应用程序中验证自己。然后用户在 IP 系统上进行身份验证过程,当他回来时,我们将他的用户名(IP 用户名)存储在我们的数据库中。因此,下一次,在身份验证阶段,我们可以检查该用户是否已在我们的系统中注册。
如果上述理论是正确的,那就意味着在我们的应用程序中。我们需要建立我们的会员提供商来存储来自 IP 和选择我们应用程序的用户的用户名。作为IP。我对么?设计上述流程的最佳实践是什么?
现在让我们谈谈授权和“角色”。它如何与 ACS 一起工作?ACS 是否为每个用户管理多个角色?
我的理解是,使用 ACS,您可以创建许多与 IP 而不是单个用户相关的“规则组”。如果这是正确的,我们如何管理应用程序中的角色用户?例如,假设我们有多个角色,并且我们的用户可以与这些角色相关联,我们可以使用 ASC 来管理它吗?
所以最后的问题是:ACS 本身是否涵盖了整个身份验证和授权过程?我们还需要使用 .net Membership Provider 吗?为了满足我们的要求,最佳实践是什么?