Microsoft Asp.Net Identity 2.0-实体框架与自定义提供程序

我正在写一个新的网站，正在看Asp.NETIdentity2.0。开箱即用，它使用实体框架进行所有数据访问。对于站点的其余部分，我们正在创建用于数据访问的中间件web服务。出于安全考虑，我们最初的计划是web服务器与中间件通信，中间件通过实体框架与数据库通信。我们计划通过防火墙阻止来自web服务器的数据库访问

我发现我可以为Identity 2.0创建一个定制的提供者，然后它就可以使用中间件进行数据访问

以下是我的问题：

不允许web服务器直接访问数据库是否更安全

如果它更安全，为什么微软不以这种开箱即用的方式构建它呢

如果您像我们一样从零开始，您会建议使用实体框架还是编写一个通过中间件层的自定义提供程序

谢谢。

1。）它是安全的。我不认为这是一个安全问题，但耦合问题。如果将来要升级或更改实体框架，该怎么办？如果您想从Identity 2.0更改，该怎么办？如果您想升级其中一个，但由于另一个尚不支持而无法升级，该怎么办

2.）微软想首先推广it产品。为了简单起见，如果您对Entity Framework和Identity 2.0满意，并且不介意它们的耦合程度，那么这可能是一个完美的解决方案

---

3.）您能在定制提供商身上花费多少时间/精力？创建自己的提供者可能不值得

Asp.NET现成标识实际上是实体框架上的Asp.NET标识。它为您生成一个数据库、连接字符串、模型文件、控制器和一个上下文类，您可以将其重定向到自己的数据库，以便它在其中生成标识表。一切都非常安全，他们已经为您处理了很多身份验证/密码哈希。我不会说创建自己的提供者是值得的，但如果您愿意，也可以在Identity中创建自己的提供者。身份2.0很棒。添加自定义表属性等非常容易。

为什么不创建一个“安全”web服务，并在其中执行ASP.Net标识，从您的网站调用它呢？1.某些地方最终需要访问数据库。2.微软提供了这些库。如何实现它们是另一回事。3.我会按原样使用ASP.NET标识，然后在需要时将其他业务逻辑/数据访问移到您的web服务中。是的-我想我正在从安全角度寻找最佳做法。。。