Перенаправление и передача данных сеанса на другой сервер / домен после входа в систему

Question

После некоторого времени поиска и чтения документов я решил спросить вас, ребята.

Итак, сценарий «прост»:

Пользователь переходит на https://Domain1.com, вводит свои учетные данные, пытается войти в систему.

После успешного входа в систему на основе типа пользователя и другой информации из БД, Сервер Domain1 должен перенаправить пользователя на другой CF-сервер по номеру https://Domain2.com.

Пока нет проблем, используя HTTP 301 и cfheader / cflocation. Я перенаправляю пользователя на вторую машину, НО он должен повторить процедуру регистрации, которая недопустима для нашего руководства.

Существует ли какая-либо хорошая и безопасная практика, которая используется для "передачи" клиента вместе с данными сеанса на другой компьютер или, по крайней мере, для автоматического входа в него с такими же учетными данными?

Как бы вы это сделали?

Answer 1

Вероятно, есть много способов справиться с этим.Вот некоторые возможные варианты.

1. "Корпоративный" способ обработки этого состоит в использовании некоторой реализации единого входа (SSO), такой как Shibboleth, для обработки.Это сложно, но очень эффективно и безопасно.

2. Прежде чем перенаправить пользователя, вы можете сгенерировать токен, который вы храните где-то (область сервера, БД), который указывает, что пользователь вошел в систему,Затем, когда вы перенаправляете этого пользователя, отправьте этот токен (http://domain2.com/HGF394JFJk58fjJ). Когда второй сервер получает запрос, если он видит, что токен присутствует, он может отправить удаленный запрос (cfhttp) обратно на первый сервер, чтобы выяснить, является ли ондействительный токен. Если это так, просто войдите в систему пользователя на втором сайте. Конечно, вам нужно будет сделать что-то, чтобы токен не мог быть повторно использован / воспроизведен.

3. Послепользователь заходит на сайт 1, вы можете отправить удаленный запрос (cfhttp) на сайт 2, чтобы войти в систему. Затем на странице (с сайта 1) отображается страница, на которой загружен фрейм iframe с сайта 2 для установки файлов cookie сеанса для сайта 2.. Это не так чисто и потребует от вас показать хотя бы одну страницу с сайта 1 перед перенаправлением на сайт 2. Мне действительно не нравится этот вариант, и я подозреваю, что он будет подвержен ошибкам и хрупок.

Как я уже сказал, возможно, есть и другие варианты. Некоторые могут быть даже лучше (хотя я сомневаюсь, что лучше, чем вариант 1). Я бы выбрал вариант 1, если у вас естьресурсы, доступные для этого.

Answer 2

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

Есть несколько презентаций и около о том, как это сделать, но 9 раз из 10 это просто не стоит хлопот.

Вы можете сделать это, используя Клиентские переменные, хранящиеся в базе данных , и передавать CFID и токены между приложениями, но это (опять же) способ, которым злой пользователь может перехватить действительный запрос пользователя .