2014-01-11 3 views
12

Я использую следующий код в сайте MVC5:объект FormsAuthentication устаревшее [используя MVC5]

[HttpPost] 
[ValidateAntiForgeryToken] 
public ActionResult Login(LoginModel loginModel) { 
    if (ModelState.IsValid) { 
     var authenticated = FormsAuthentication.Authenticate(loginModel.UserName, loginModel.Password); 
     if (authenticated) { 
      FormsAuthentication.SetAuthCookie(loginModel.UserName, true); 
      return RedirectToAction("AdminPanel"); 
     } 
     ModelState.AddModelError("", "The username and password combination were incorrect"); 
    } 
    return View(loginModel); 
} 

Какие подбрасывает следующее предупреждение:

System.Web.Security.FormsAuthentication. Аутентификация (строка, строка) ' устарела:' Рекомендуемая альтернатива - использовать API-интерфейс Membership , например Memberhip.ValidateUser. Для получения дополнительной информации см. http://go.microsoft.com/fwlink/?LinkId=252463. '

Первый отказ от ответственности - я один из тех разработчиков, которым нравится постоянно следить за вещами, и я предпочитаю избегать предупреждений в VS полностью. Однако в данном конкретном случае, я использую крайне примитивную идентификацию, которая поступает непосредственно из web.config следующим образом:

<authentication mode="Forms"> 
    <forms loginUrl="~/account/login" timeout="2880" slidingExpiration="true" name=".ASPXFORMSAUTH"> 
     <credentials passwordFormat="SHA1"> 
      <user name="MyUserName" password="a-big-long-password-hash"/> 
     </credentials> 
    </forms> 
</authentication> 

Существует абсолютно никаких дополнительные требования для входа в этом проекте - использование базы данных не является излишеством, и нет необходимости в распределенном входе; в основном, сохранение деталей в web.config является самым идеальным решением, и, вероятно, будет только один пользователь для каждого приложения. Я, без сомнения, отвлечу код аутентификации от контроллера (используя DI/IoC), но я все еще намерен использовать объект FormsAuthentication для аутентификации против деталей в web.config.

Хотя я полностью осведомлен о поставщиках членства, DotNetOpenAuth и новой (но довольно ужасной) модели аутентификации на основе OWIN, приведенный выше код более чем достаточен.

Первый вопрос - Почему FormsAuthentication была устаревшей, когда это вполне допустимый прецедент? Я понимаю, что FormsAuthentication является запечатанным черным ящиком, его трудно проверить, а код, стоящий за ним, зависит от домена, но в этом конкретном экземпляре (где я хочу читать данные непосредственно из раздела web.config), кажется, безумие написать поставщик членства или пользовательскую службу проверки подлинности?

Второй вопрос. Если я чего-то не упускаю, новая модель OWIN предназначена для распределенной аутентификации и не подходит для системы безопасности на уровне предприятия. Из многих сообщений в блогах, официальных документов и сообщений, которые я прочитал, также кажется, что он еще неполный. Правильно ли я в своих предположениях? Является ли OWIN будущим всех систем безопасности, или я должен продолжать писать на заказ системы безопасности, более подходящие для моих клиентов?

ответ

6

К вашему первому пункту мы устарели, потому что это не соответствует современным стандартам безопасности. Он использует прямой хеш без итерации, а это значит, что любой, кто обращается к вашему Web.config, может легко понять, что такое исходные пароли. Но если вы готовы принять эти риски, вы, безусловно, можете продолжать использовать его в будущем. Просто подавите предупреждение и пасьянс своим исходным кодом.

К вашему второму пункту, нет никакого отношения между любым из этого и OWIN.

Надеюсь, что это очистит!

+0

Спасибо за ваш ответ Levi. В таком случае, что является предпочтительным способом достижения простой аутентификации, например, в моем примере? Знаете ли вы какие-либо документы или статьи, предлагающие какие-либо альтернативы, или рекомендуемый способ внедрения членства и собственных алгоритмов хранения и хеширования? Я делал это много раз в более сложных системах, но я чувствую, что в этом конкретном случае это слишком много. – Spikeh

+1

Если вы чувствуете, что это лишний случай для этого конкретного случая, игнорируйте предупреждение (или подавляйте его с помощью предупреждения #pragma warning disable). Вы можете продолжать использовать этот оригинальный метод, если он подходит для вашего сценария. Если вы хотите что-то более безопасное, вы можете использовать Crypto.HashPassword http://msdn.microsoft.com/en-us/library/system.web.helpers.crypto.hashpassword(v=vs.111).aspx и Crypto. VerifyHashedPassword http://msdn.microsoft.com/en-us/library/system.web.helpers.crypto.verifyhashedpassword(v=vs.111).aspx из сборки System.Web.Helpers.dll. – Levi

6

OWIN - это не только безопасность. Это стандарт, который определяет интерфейсы между инфраструктурой приложения (ASP.NET MVC) и веб-сервером (IIS). Это новый уровень абстракции Microsoft, который позволяет разработчикам .NET писать приложения, которые не являются агностиками хоста, то есть не зависят от IIS.

Архитектура OWIN - это конвейер, состоящий из множества компонентов промежуточного программного обеспечения. В MVC5 безопасность была переписана с нуля как компонент промежуточного программного обеспечения OWIN. Если это не сработает для вас, и вы хотите запустить свою собственную процедуру проверки пароля, вы можете реализовать свое собственное промежуточное программное обеспечение безопасности. Вот post, описывающий, как это сделать.

Если вы не хотите идти так далеко, это post показывает, как полагаться на встроенную в рамках проверки подлинности без членства

Все Леви упоминается еще в силе, хотя. Вы хотите быть осторожным с собственным механизмом хеширования/хранения и выбрать хороший алгоритм хэширования.

Вот еще дополнительная информация о безопасности OWIN midddleware, реализованная Microsoft.