Безопасна ли следующая схема для сеансов, распределенных по нескольким службам?

Question

Я разрабатываю клиент-серверное приложение, которое будет общаться через Интернет.Однако сервер состоит из нескольких отдельных сервисов, и я хочу, чтобы пользователь только аутентифицировался один раз.

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

Есть ли какие-либо недостатки этой схемы по сравнению, например, с использованием запроса / ответа на идентификатор сеанса или куки-файлы аутентификацииподписано сервером?Все сервисы являются доверенными, поэтому нет необходимости защищать сервис (ab), используя идентификатор сеанса соединения для олицетворения пользователя.

Answer 1

Основной проблемой является то, что клиент отвечает за передачу идентификатора сеанса в виде запроса GET или POST между серверами, что делает эту систему уязвимой для Фиксация сеанса . Из этого описания не ясно, как передается состояние сеанса или кто отвечает за эту информацию.

Я согласен, что cookie должен быть очень большим случайным числом, называемым Cryptographic Nonce . Эта переменная используется в качестве ключа для доступа к состоянию на стороне сервера. В случае распределенного сеанса самое простое решение состоит в том, чтобы иметь отдельный сервер или базу данных, которые могут нести ответственность за поддержание состояния во всех доменах. Это облегчает задачу, поскольку пользователь может одновременно работать с несколькими доменами, не беспокоясь о состоянии гонки. Когда серверу необходимо установить или получить переменную сеанса, он отправит запрос на общий сервер сеанса.

Для переноса пользователя с одного сервера на другой без введения уязвимости фиксации сеанса необходимо создать одноразовый «Transfer Id», который также должен быть криптографическим одноразовым номером. Коммунальный сервер знает, что пользователь был помечен для передачи. Браузер клиента передает этот «Transfer Id» на новый сервер, новый сервер ищет пользователя на основе «Transfer Id», а затем новый сервер заново генерирует идентификатор сеанса, который будет использоваться для этого домена. Одним из способов является использование традиционного обработчика сеансов, чтобы каждый сервер имел уникальный идентификатор сеанса. Отдельный сервер может хранить информацию о состоянии, чтобы связать этот идентификатор сеанса с состоянием определенного пользователя в распределенной системе.