Совместное использование системы входа между классическим ASP и ASP.Net

Клиент использует классический ASP для входа в свою веб-службу.

Я написал новое приложение ASP.Net для включения в backoffice, и мне нужно использовать уже существующую систему входа, так что, когда они войдут в систему, им не нужно снова входить в систему новое приложение ASP.Net.

Логины и пароли хранятся как чистый текст в SQL Server db, доступ к которому я могу получить из своего приложения ASP.Net.

Каким будет эффективный способ интеграции этих систем?

Моя лучшая идея: В ссылке на мое приложение ASP.Net я ссылаюсь на страницу входа "шлюз" со своим идентификатором пользователя и хэшированным паролем + общий секрет в строке запроса. Затем я сравниваю это с паролем пользователя в базе данных... Но проблема в том, что если эта переадресация перехвачена, ее можно использовать для доступа к сайту asp.net без фактического знания имени пользователя и пароля...

Я, скорее всего, пропущу что-то простое.

Ответ 1

Я думаю, что ваша идея на правильном пути.

Как вы, наверное, уже знаете, классические asp и asp.net не могут совместно использовать одно и то же состояние сеанса, поэтому вам нужно иметь механизм для входа из одного в другой.

Я бы сделал так: когда кто-то войдет в систему, создайте уникальный GUID, который вы сохраните в базе данных для этого пользователя. Когда вы переходите с одного сайта на другой, передайте этот GUID в строку запроса. Когда вы пытаетесь автоматически зарегистрировать их на другом сайте, найдите этот GUID и посмотрите, привязан ли он к кому-либо. Если это так, запишите их.

Таким образом, вы не передаете ничего, что пользователь мог угадать или расшифровать.

Ответ 2

Как классическая система ASP поддерживает состояние входа? "Скотч-поддержка", это будет вашим лучшим выбором, безусловно.

Все классические ASP-системы, над которыми я работал, использовали файлы cookie для отслеживания данных аутентификации, поэтому просто прочитайте их и сравните с доступной базой данных.

Поскольку информация хранится в классическом сеансе ASP, вы могли бы добавить "страницу перенаправления" к классической стороне ASP вещей, которая является "входом" в новый модуль, и заставить это написать полезные данные как куки или запустить POST на стартовую страницу? Используя файлы cookie или POST-запрос, вы минимизируете свое беспокойство по поводу того, что URL-адрес "захвачен" позволяет кому-то попасть на сайт ASP.net без имени пользователя и пароля.

Ответ 3

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

"GUID в подходе к базе данных" - это то, что я успешно использовал в прошлом, как для передачи пользователям между двумя приложениями, использующими одну и ту же базу данных аутентификации, а также для сценариев типа "пароль reset email". Вы можете "закончить" это, указав дополнительный столбец в записи, указав дату, в которую был добавлен GUID, и измените код вашего приложения, чтобы регистрировать только идентификаторы GUID, которые меньше, чем x минут/часов/дней.

Альтернативой может быть избежание дополнительных полей в базе данных путем объединения чего-то типа:

UserId + [Value representing current time to nearest x minute / hour /day] + Salt

.. хеширование, затем дублирование вашего алгоритма в другом приложении и сравнение двух сгенерированных значений.

В общем, я думаю, что ваше предлагаемое решение подходит к проблеме. Это, конечно, не слишком сложно.

Ответ 4

Не могли бы вы отправить его через форму, а не через Querystring? Это исключило бы возможность его перехвата в URL-адресе.

Ответ 5

Если перехват является серьезной проблемой, вам необходимо запустить сайт через HTTPS. В противном случае использование UserID + Nonce, которое затем хешируется паролем, является достаточно сильным.

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