MVC3 Слабосвязанная аутентификация

Question

Изначально приложения MVC3 разрешают проверку подлинности Windows при использовании шаблона проекта в интрасети или проверку подлинности с помощью форм для шаблона проекта в Интернете.У меня есть сайт, который я хотел бы использовать либо.Кроме того, у меня есть существующий сайт, который использует свой собственный тип аутентификации, который аутентифицирует пользователей (без авторизации или ролей, только идентификация).Мне может понадобиться использовать функциональность каждого из них в дополнение к данным из прежней системы для аутентификации.В связи с этим я пытаюсь определить способ абстрагировать свою аутентификацию и отделить ее.Я хотел бы использовать какое-то внедрение зависимости, полностью основанное на конфигурации, чтобы я мог развернуть этот же сайт в двух разных местах и ​​переключить модель аутентификации (Windows Auth / Forms Auth / Custom Auth), изменяя только конфигурацию.

В настоящее время все приложения ASP.NET, с которыми я работал, включая шаблоны проектов MVC3, похоже, очень тесно связаны с используемым типом аутентификации.

Думаю ли я слишком далеко за пределами коробки на этом?

Возможно ли это, или есть причина такой жесткой связи?

ОБНОВЛЕНИЕ Реальная проблема, с которой я сталкиваюсь, заключается в существующей устаревшей аутентификации, которую мне нужно использовать для некоторых пользователей, и аутентификации на основе форм, которая мне нужна для других.Проверка подлинности Windows и форм на самом деле не является проблемой, поскольку форма входа не используется ни для одной из них.Но рассмотрим пользовательскую аутентификацию и аутентификацию по формам.Форма входа в систему тесно связана с FormsAuthentication, более конкретно с System.Web.Security.(т.е. Membership.ValidateUser, FormsAuthentication.SetAuthCookie и т. д. ...).

Я бы хотел ввести в свой AccountController аутентификацию для использования вместо использования FormsAuthentication и Membership.

Имеет ли это смысл в моей проблеме?

Answer 1

Я согласен с ответом Крейга. Единственное, что я должен добавить, это то, что я считаю, что все, что вы можете изменить в файле web.config, является слабосвязанным. Причина в том, что вы можете применить преобразования web.config при создании пакета развертывания для приложения MVC.

Мы используем Unity для DI / IoC, и вы также можете указать свои инъекционные зависимости в web.config, используя Unity. Вы просто напишите свой Web.Auth1.config, чтобы настроить свое приложение для одного вида аутентификации, и Web.Auth2.config, чтобы настроить его для другого вида аутентификации. Затем при развертывании вы просто выбираете цель, и VS создает для вас правильную конфигурацию.

Если вашему исходному коду необходимо знать, какой тип аутентификации используется при развертывании, вы можете сообщить об этом с помощью набора приложений web.config, который также можно изменить с помощью преобразования web.config во время развертывания.

Answer 2

Они на самом деле не так тесно связаны. Шаблоны просто пытаются быстро настроить и запустить вас.

Членство в ASP.NET поддерживает аутентификацию с помощью форм и домена.

На сайте, настроенном для проверки подлинности с помощью форм, например, вы увидите строку в Web.config, например:

<authentication mode="Forms">

Вы можете изменить это на:

<authentication mode="Windows">

Это не единственное отличие (при аутентификации Windows, например, не требуется страница входа в систему), но это самое важное. Вы пишете свой код на основе API членства ASP.NET и ориентируетесь только на проверку подлинности с помощью форм, особенно когда это необходимо.