Как перенести приложения из классического ASP в ASP.NET MVC?

В настоящее время у нас есть много веб-приложений (внешних и внутренних), разработанных с использованием технологий Classic ASP через .NET 2.0. Каждое из этих веб-приложений имеет свой собственный экран входа в систему, аутентифицирующий свою собственную базу данных или проверку подлинности Windows. Пользователи имеют доступ к одному или нескольким из этих приложений, то есть они должны выйти из системы и вернуться в приложения, к которым они хотели бы получить доступ. Все приложения используют часть исходных источников данных. Кроме того, бизнес-логика встроена в пользовательский интерфейс в дополнение к дублированию между приложениями, потому что нет совместного использования кода/бизнес-логики. Скриншот # 1 дает краткое представление о существующей архитектуре.

Снимок экрана # 2 показывает предлагаемую архитектуру, которая, я надеюсь, поможет в более быстрой разработке, повторном использовании кода/бизнеса и может быть упрощенном обслуживании. Пользователи получат доступ к внешнему или внутреннему URL-адресу. На внешнем уровне пользователи будут предоставлять учетные данные и будут аутентифицированы против пользовательской базы данных. На внутреннем сайте пользователи будут автоматически регистрироваться с помощью проверки подлинности Windows. После создания некоторых образцов мне стало нравиться ASP.NET MVC 3. Он сохраняет бизнес-логику отдельно от пользовательского интерфейса, и мне также нравятся возможности модульного тестирования.

Вот мои вопросы:

Основываясь на том, что я нашел в Интернете до сих пор, несколько аутентификаций не могут быть реализованы на одном веб-сайте. Я понимаю, что для каждого типа проверки подлинности (форм и Windows) я должен разместить один веб-сайт. Как перенаправить пользователей на общую целевую страницу после их аутентификации, чтобы они могли видеть модули (ссылки/меню), к которым у них есть права доступа? Должен ли я опубликовать тот же набор кодов (dlls и content) на оба веб-сайта?
Кто-нибудь сталкивался с подобной проблемой архитектуры? Если да, не могли бы вы рассказать о проблемах, с которыми вы столкнулись, и о том, как вы их решаете? Каковы отраслевые стандарты при разработке приложений такого рода?
Предлагает ли предлагаемая архитектура какой-либо смысл или это действительно плохой дизайн? Есть ли недостатки в этом в ASP.NET MVC 3?

Я бы очень признателен за ваши материалы.

Спасибо заранее.

Ответ 1

Я бы создал отдельный веб-сайт, который обрабатывает только проверку подлинности Windows. Затем я полагался на что-то вроде OpenID и/или OAuth, чтобы запрашивать учетные данные/токен, чтобы убедиться, что у пользователя есть правильный доступ.

Пользователь, который хочет войти в систему с использованием учетных данных Windows, проходит этот процесс, потому что вы правы в том, что сервер IIS с проверкой подлинности Windows трудно смешивать с другими материалами.

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

Ответ 2

Имейте в виду разницу между Аутентификация и авторизация. Предположительно, вам нужен единый механизм аутентификации (или, возможно, два, один для внутреннего и один для внешних пользователей). Здесь есть аналогичная статья, в которой изложены некоторые довольно хорошие рекомендации: Как разрешить несколько методов проверки подлинности в ASP.NET?

Ответ 3

В одном проекте мы построили общий класс контроллера, используемый на каждой странице сайта. Он обрабатывал проверку подлинности и контроль доступа. Когда пользователь попытался получить доступ к любой странице, которую он проверил, чтобы проверить, есть ли у них файл cookie идентификации сеанса. Если они этого не сделали, они должны были пройти аутентификацию (логин). Задача заключалась в эффективном осуществлении безопасности. В современных браузерах есть много недостатков, которые затрудняют это.