Совместное использование системы входа между классическим 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.
