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

Question

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

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

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

1. Исходя из того, что я обнаружил в Интернете, несколько аутентификаций не осуществимы на одном веб-сайте. Насколько я понимаю, мне нужно разместить один веб-сайт для каждого типа аутентификации (Forms и Windows). Как перенаправить пользователей на общую целевую страницу после проверки подлинности, чтобы они могли видеть модули (ссылки / меню), к которым у них есть права доступа? Должен ли я публиковать один и тот же набор кодов (dll и контент) на обоих сайтах?

2. Кто-нибудь сталкивался с подобной проблемой архитектуры? Если да, не могли бы вы рассказать о проблемах, с которыми вы столкнулись, и о том, как вы их решили? Каковы отраслевые стандарты в разработке приложений такого рода?

3. Имеет ли предлагаемая архитектура какой-либо смысл или это действительно плохой дизайн? Есть ли какие-либо недостатки в этом в ASP.NET MVC 3?

Буду очень признателен за ваш вклад.

Заранее спасибо.

Answer 1

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

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

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

Answer 2

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

Answer 3

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