Безопасность в системе распределенных веб-приложений

Question

У меня есть набор из трех систем веб-приложений - A, B & C, которые используются для обслуживания моего приложения. Система A имеет основную бизнес-логику, а также хранит данные пользователя / учетной записи для всего приложения. Системы B & C необходимы для обеспечения дополнительной функциональности приложения.

Я думал о механизме защиты, при котором пользователь U входит в основную систему A, и система создает маркер безопасности для текущего сеанса, который потребуется для аутентификации запроса от пользователя U в другие системы B & C. В тот момент, когда пользователь входит в систему A, он внутренне генерирует токен и отправляет токен xyz в подсистемы B & C. Теперь всякий раз, когда пользователь U отправляет запрос подсистемам B & C с действительным токеном. пользователю будет разрешен доступ к ресурсам. Но тогда я не уверен, что это лучший или даже правильный подход.

Итак, я немного озадачен полным процессом и любая помощь в этом отношении будет высоко оценена.

Я занимаюсь разработкой на Java, и поэтому любой модуль, который им управляет, уже сэкономит мне много времени на разработку. Пожалуйста, ведите меня.

Answer 1

Эта модель, которую вы описываете, является формой доверительного депонирования, когда несколько клиентов доверяют третьей стороне для обработки аутентификации пользователя.

См. Распределенную систему безопасности Kerberos.

Протокол Kerberos и его реализация веб-приложения Stanford WebAuth имеют несколько преимуществ по сравнению с тем, что вы описываете:

• Нет необходимости отправлять токен из A в B + C, когда пользователь входит в систему. Вместо этого A («KDC» в терминах Kerberos) делит секрет с B («Kerberized server») и один с C только при начальной настройке доверительных отношений.
• Токен не может быть перехвачен, поскольку он никогда не отправляется в открытом виде из A пользователю.

Если вам не требуется полноценная аутентификация Kerberos, которая может быть сложной для реализации, я бы рекомендовал такую ​​модель:

• Пользователь Джо аутентифицируется в A, предпочтительно используя протокол ответа на запрос, который не включает отправку пароля Джо в A
• Криптографически подписывает имя пользователя Джо, текущее время и какой-то случайно сгенерированный мусор
• B и C принимают пользователей в течение указанного периода времени, которые могут представлять пакеты, подписанные A, содержащие их имя пользователя и соответствующее время

Это базовый протокол аутентификации-токена. Он имеет несколько недостатков, но все же лучше, чем отправлять пароль пользователя.

Answer 2

Эта схема также будет работать: вы можете перенаправить все запросы на сервер A, B и C, во-первых, только на сервер A для аутентификации, так как он содержит все ваши данные, относящиеся к пользователю.Теперь, как только запрос был аутентифицирован (каким методом вы предпочитаете), и в вашей бизнес-логике вам нужно сделать ВНУТРЕННИЙ вызов между серверами.Для этого вы можете использовать внутренних пользователей, которые во время развертывания создаются на каждом из серверов, а их авторизационный токен хранится в кошельке.Извлеките токен аутентификации для этого внутреннего пользователя из кошелька и инициируйте вызов, другой сервер авторизует пользователя.Примечание. Если вам когда-либо понадобится тот, кто является действительным пользователем, выполняющим эту операцию, эта информация не может быть получена из токена аутентификации, поскольку токен принадлежит внутреннему пользователю.В этом случае вы можете передать текущее имя пользователя, вошедшего в систему, в заголовке авторизации http.