我正在尝试使用最新的EF在Azure上设计MVC4.5网站，但却坚持设置成员身份和角色基础身份验证。
我在MembershipProvider，SimpleMembershipProvider和ExtendedMembershipProvider中有点迷失。
我发现，与SqlMembershipProvider不同，SimplememberShipProvider不是为了在单个数据库中存储多个应用程序（通过ApplicationName和ApplicationID）而相应地映射用户，因此企业可以只使用一个数据库运行多个应用程序。
我听到了SimpleMembershipProvider的所有赞美，我的问题是如何设计数据库/提供者，以便我能够将用户与各个应用程序关联存储在单个数据库中。用户注册信息必须完全独立于其他应用程序中的相同用户名。我还需要开放式身份验证的新功能。
从广义上讲，我的疑问是：
是否可以使用SimpleMmebershipProvider来区分单个数据库中的多个应用程序。
我正在考虑修改SimpleMembershipProvider所包含的现有架构结构以包含ApplicationId列，但是，即使是从扩展成员资格提供程序继承的自定义提供程序也会对任何用户添加ApplicationId。
是否有其他提供商或任何文章可以指导实施自定义成员资格提供程序以及自定义数据库设计以及开放式身份验证的功能。
或者我采取完全错误的做法？
回答BernardG
的查询您想要一个“头”网址/网站，然后将用户重定向到正确的位置 申请，或
不，网站不应该显示为相关，也不会重定向到其他网站。
同样不，每个应用程序都应该有自己的注册过程。另外两个应用程序可以使用相同的用户名，但这些帐户不相关。
用户可以注册任何应用程序吗？
是
如果没有，你如何限制？
不限制。
这是什么意思？“用户注册信息必须完整 在其他应用程序中独立于相同的用户名。“
参考第2点的答案，如果有4个应用程序有一个数据库且用户注册了一个应用程序，他必须再次注册才能访问其他应用程序。因此，对于任何用户，网站都不得显示相关。
您想将用户信息复制到每个应用程序中吗？
根据我对该问题的理解，即使使用不同的个人资料信息，用户名和电子邮件地址的组合（考虑到此组合使任何用户帐户都是唯一的）也可以再次存储在另一个应用程序中。
实际上我已经习惯了ASP.net 2.0中使用的经典成员资格方法，而且我错过了用于分离的应用程序Id列。
答案 0 :(得分：1)
如果可以的话，我相信你的问题与设计有很大关系，并且清楚地建立你想要的功能，而不是特定的会员提供者，知道你可以用SimpleMembership做任何你想做的事情。
我的问题，我相信这些是你在进一步研究之前要问自己的问题，是：
您想要一个“头”网址/网站，然后将用户重定向到正确的位置 申请，或
您希望用户进入任何应用程序吗？ 然后被重定向到他注册的另一个。
用户可以注册任何应用程序吗？
如果没有，你如何限制？
这是什么意思？“用户注册信息必须完整 在其他应用程序中独立于相同的用户名。“
您是否要将用户信息复制到每个应用程序中？
在我看来，这完全是关于数据库的设计和分析，以满足您的实际需求。一旦完成，关于成员资格表的部分将很容易解决。