ASP.NET MVC /网络API自定义身份验证 [英] ASP.NET MVC / Web API Custom Authentication

问题描述

我有ASP.NET MVC 4 /网页API混合应用程序。认证是由现有的应用程序处理。在寻找保护这些类型的应用，大多数文章指出使用窗体身份验证与沿[授权] 属性的MVC和API控制器/要保护行动。我想使用 [授权] 属性，因为它会同时处理MVC路线和API的路线，但不知道该怎么做，而无需实际的形式，并使用内置在成员提供。

I have ASP.NET MVC 4 / Web API hybrid application. The authentication is being handled by an existing application. In looking at securing these types of applications, most articles point to using Forms Authentication along with the [Authorize] attribute on the MVC and API controllers/actions you want to protect. I would like to use the [Authorize] attribute as it will handle both MVC routes and API routes but not sure how to do that without having an actual form and using the built-in membership provider.

我应该去像描述一个简单的方法这里？或者我应该创建处理逻辑的定义成员资格提供？

Should I go with a simple approach like described here? Or should I create a Custom Membership provider that handles the logic?

有关的清晰度，工作流将是如下：

For clarity, the workflow would be as follows:

1. 用户通过现有的认证门户登录


2. 如果通过身份验证，他们像用户名和电子邮件（所以没有密码需要转移）
一些额外数据一起重定向到我的应用程序

3. 我的应用程序设置身份验证Cookie，允许用户继续使用该应用程序。

1. The user logs in through the existing authentication portal.
2. If authenticated, they are redirected to my application along with some additional data like username and email (so no passwords need to be transferred)
3. My application sets an authentication cookie that allows the user to continue using the application.

任何帮助将大大AP preciated。

Any help would be greatly appreciated.

推荐答案

• 选项1

如果您现有的登录门户网站使用窗体身份验证，那么你就可以分享应用程序之间的加密密钥，使他们可以阅读登录门户创建的身份验证Cookie：

If your existing login portal is using Forms Authentication, then you can share the encryption keys between the applications so that they can read the authentication cookie created in the login portal:

<一个href=\"http://stackoverflow.com/questions/5161562/how-can-i-share-net-c-based-authenticated-session-between-web-forms-and-mvc2\">How我可以分享的.NET（C＃）Web Forms和MVC2应用之间基于认证会话？

• 选项2

如果你不是在登录门户网站使用窗体身份验证，可以保留现有的流程，但增加上手动创建身份验证cookie的一个步骤。有很多在此变型的，但这个问题显示在提问更高水平的方式，并在回答一个较低水平的方法：

If you're not using forms authentication in the login portal, you could keep your existing process, but add on a step that manually creates the authentication cookie. There are lots of variations on this, but this question show a higher level way in the question, and a lower level method in the answers:

<一个href=\"http://stackoverflow.com/questions/7217105/asp-net-how-can-i-manually-create-a-authentication-cookie-instead-of-the-defau\">ASP.NET - 如何可以手动创建一个身份验证cookie，而不是默认的方法

此也需要加密配置是应用之间的相同。

This also requires the encryption configuration be the same between the applications.

• 选项3

否则你要么留下使用SSO协议进行切换。你可以保持现有的认证过程为您登录门户，但将需要添加额外的code协调SSO切换到其他应用程序。 SSO出现，因为比＃1和使用加密的cookie的方法等;以上2，有做一个浏览器重定向和通信认证很少其它安全选项。

Otherwise you are either left with using an SSO protocol for the handoff. You can keep the existing authentication process for your login portal, but will need to add additional code to coordinate the SSO handoff to the other application. SSO came about because other than encrypted cookie methods used in #1 & 2 above, there is little other secure options for doing a browser redirect and communicating authentication.

创建自己的基于Cookie的方法是有风险的，并可能开辟你没有预见的安全漏洞。

Creating your own cookie based method is risky and may open up security holes that you don't foresee.

• 我应该去像描述一个简单的方法<一href=\"http://stackoverflow.com/questions/18594316/custom-authentication-and-asp-net-mvc\">here?\"

• "Should I go with a simple approach like described here?"

有关的例子最重要的是，目前还不清楚其中username是从 SetAuthCookie未来（用户名，... 。这个问题意味着，用户将登录到额外的应用程序，该应用程序将查询Web服务，以确定是否该登录是有效的。在这种情况下，它不是一个专门的登录门户单点登录，而是每个应用程序收集登录信息，并要求网络API，如果它是有效的。在你的情况，你不想来收集各门户网站的登录信息，而是发现他们已经登录到deicated登录门户。

The important thing about that example is it's not clear where username is coming from in SetAuthCookie(username, .... That question implies that the user will login to the additional application and that app will query the web service to determine if that login is valid. In this case it's not single sign on with a dedicated login portal, but instead each app collects login information and asks the web API if it is valid. In your case, you do not want to collect the login information in each portal, but instead detect that they've already logged in to the deicated login portal.

所以，问题是如何登录门脉告诉你一个安全的方式是什么用户名是当你调用 SetAuthCookie（用户名，... 。这正是SSO是什么。使用SSO切换，一个网站可以告诉对方以安全的方式说：我送Bob123给你，你可以肯定这是真的Bob123和不是别人。

So the problem is how does the login protal tell you in a secure fashion what username is when you call SetAuthCookie(username, .... That's exactly what SSO is for. Using a SSO handoff, one site can tell the other in a secure fashion that "I'm sending Bob123 to you, and you can be sure it is really Bob123 and not someone else.

选项＃1和＃2解决这个问题通过具有登录门户设置cookie，而是和通过在应用程序共享键，其他的应用程序可以安全地读取该cookie。

Options #1 and #2 get around this by having the login portal set the cookie instead, and by sharing keys across the apps, the other apps can securely read that cookie.

请注意，你不能只用任何的cookie做到这一点。该窗体身份验证cookie是建立在一个特定的方式到cookie的prevent伪造和篡改等。

Note you can't do this with just any cookie. The forms authentication cookie is built in a certain way to prevent forgery of the cookie and other tampering.

SSO成为你唯一的选择，如果你要在域，因为写在一个域中的cookies不能在另一个（浏览器只提交饼干当前comain）读取。

SSO becomes your only option if you are going across domains because cookies written in one domain cannot be read in another(the browser only submits cookies for the current comain).

有与多个子域共享一个根域窗体身份验证解决方法：

There are workarounds for forms authentication with multiple subdomains sharing a root domain:

<一个href=\"http://stackoverflow.com/questions/15076138/proper-creation-of-a-cross-domain-forms-authentication-cookie\">Proper创建一个跨域窗体身份验证cookie 的

有重定向到与加密信息其他网站，并让该网站写窗体身份验证cookie各种黑客，但大多都只是可怕的黑客是一样SSO那么复杂。

There are various hacks for redirecting to another site with encrypted information and letting that site write the forms authentication cookie, but most of them are just horrible hacks that are just as complicated as SSO.

这篇关于ASP.NET MVC /网络API自定义身份验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！