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

Question

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

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

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

Возможно ли это, или есть причина для этой плотной муфты?

UPDATE Реальная проблема у меня есть между существующей устаревшей аутентификацией мне нужно использовать для некоторых пользователей, по сравнению с аутентификацией Forms мне нужно для других. Проверка подлинности Windows и Forms на самом деле не является проблемой из-за того, что форма журнала не используется для одного. Но рассмотрите аутентификацию пользовательской аутентификации и формы. Форма LogIn тесно связана с FormsAuthentication, в частности с System.Web.Security. (т. е. Memberhip.ValidateUser, FormsAuthentication.SetAuthCookie и т. д.).

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

Означает ли это, что до сих пор имеет значение моя проблема?

Answer 1

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

Членство в ASP.NET поддерживает как формы, так и полномочия домена.

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

<authentication mode="Forms"> 

Вы можете изменить, что:

<authentication mode="Windows"> 

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

Answer 2

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

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

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