多层架构中的身份验证
组成。
- 我正在 .NET 中设计一个 N 层系统，该系统将由SQL Server 2008
- EF 4
- 存储库层
- 服务层（业务逻辑）
在此之上，我将拥有：
- ASP.NET MVC 网站
- 可供其他客户端使用的 外部 API（使用 WCF 或 ServceStack.NET 构建）
我想在 MVC 应用程序中实现典型的用户名/密码身份验证以及 OpenID/twitter/facebook 登录选项
API 将需要类似形式的身份验证。
架构中的哪个位置是实现身份验证的最佳位置？是否有任何可用的示例来说明如何使用 .NET Stack 实现此类功能？
自定义会员资格提供商是否可以解决此问题？
我意识到有一些库可用于实现 openID 部分，因此目前这不是一个问题，但我希望保持开放状态以在将来添加此部分。
建议？
I am designing an N-Layer system in .NET that will consist of
- SQL Server 2008
- EF 4
- Repository Layer
- Service Layer(Business Logic)
On top of this I will have:
- ASP.NET MVC website
- external API to be consumed by other clients(built with WCF or ServceStack.NET)
I would like to implement the typical username/password auth within the MVC app as well as OpenID/twitter/facebook login options
The api will need similar forms of authentication.
Where in the architecture is the best place to implement the authentication and are any samples available of how to implement something like this with a .NET Stack?
Is a custom Membership provider an option for this?
I realize that there are libraries available to implement the openID portion so that is not a concern at the moment but I would like to leave things open to add this in the future.
Suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
身份验证应在面向用户的点完成：MVC 网站和 WCF 服务。
在每一点中，使用适当的身份验证/授权机制。
MVC网站：表单身份验证（或Windows身份验证等）
WCF服务：（您将采用什么方法，API密钥，每个请求的用户/名称密码，安全密钥、auth cookie 等）
对于每个点，使用请求者（用户）使用的凭据调用服务层，并根据您的数据库（在服务层中）对其进行验证。
服务层应该返回给定的凭据的有效/无效。
如果它无效，请让您的网站或网络服务拒绝用户的任何进一步操作，并通知他们它无效。
如果它有效，请让您的 MVC 网站创建身份验证 cookie (
FormsAuthentication.SetAuthCookie)，并且您的 WCF 服务针对您选择的身份验证机制执行适当的操作。让您的服务层与身份验证无关。它应该只响应一组凭据是否有效，并且您的前端层应该负责设置身份验证票证。
对于 Open ID/Twitter/Facebook 登录，所需的所有信息都位于 Web 应用程序上（通过登录源 cookie），因此请使用它来设置网站的身份验证 cookie。
Authentication should be done at the user facing point: MVC website and the WCF service.
In each point, use the appropriate authentication/authorization mechanism.
MVC website: forms authentication (or windows authentication etc.)
WCF service: (what method will you be taking, API key, user/name password on every request, secure key, auth cookie etc.)
For each point, call the service layer with the credentials used by the requestor (user) and validate it against your database (in the service layer).
The service layer should return valid/invalid for the credentials given to it.
If it's invalid, have your website or webservice reject any further actions from the user and inform them that it's not valid.
If it's valid, have your MVC website create the auth cookie (
FormsAuthentication.SetAuthCookie) and your WCF service do the appropriate action for the authentication mechanism you chose.Keep your service layer agnostic of the authentication. It should only respond with whether or not a set of credentials is valid and your front-facing layers should take care of setting the authentication tickets.
For Open ID/Twitter/Facebook logins, all the information needed is on the web app (via the login source cookies), so use that to setup your website's auth cookie.
基本架构是使用 asp.net 会员 API 来调用同一会员数据库的服务和 Web 应用程序。然后使用模拟用户连接到 SQL Server。
然后，您可以为其他身份验证机制编写自定义成员资格提供程序，或将它们全部合并到一个成员资格提供程序中。
A basic architecture would be to use the asp.net membership api for your service and web apps calling into the same membership database. Then use an impersonated user to connect to SQL Server.
You can then write custom membership providers for the other auth mechanisms or incorporate them all into one membership provider.
抱歉，由于评论中没有足够的空间，不得不将此写为另一个答案。
在 IIS 级别配置成员资格提供程序并使用 OOTB SQL 成员资格提供程序来使基本身份验证正常工作。
然后，您可以编写自定义成员资格，存储库层将在 Web 应用程序（Web 服务或 ASP.NET 站点）的上下文中运行，以便您的身份验证信息将位于 httpContext 中，然后您可以使用它连接到您的数据库或使用模拟帐户（即应用程序池用户）进行连接。
然后，您可以编写一个自定义成员资格提供程序，根据其他提供程序进行身份验证（如果您愿意），只需将标准 SQL 替换为您的自定义提供程序即可。
Sorry had to write this as another answer as didn't have enough space in the comments.
Configure the membership provider at the IIS level and use the OOTB SQL membership provider to get basic authentication working.
You can then write a custom membership the repository layer will be running in the context of the web application either web service or asp.net site so your authentication information will be in the httpcontext, you can then use that to connect through to your database or use an impersonated account i.e. the app pool user to connect instead.
You can then write a custom membership provider that authenticates against the other providers if you like and just swap out the standard SQL one for your custom one.
作为奥马尔的回答的补充：
您还可以使用Facade Pattern 处理授权，由 WCF 和 MVC 代码使用，并向业务层提供 API。
经验法则是：将授权放在一个点上，并让授权逻辑由客户端处理。不要将其分布在您的服务层上！
As an addition to Omar's answer:
You could also use a Facade Pattern which handles the authorization and is used by both the WCF and MVC code and provides the API to the business layer.
A rule of thumb is: Put authorization at one single point and let the auth-logic be handled by the client(s). Don't spread it over your service layer!