OpenID в ситуации с балансировкой нагрузки

Question

Я рассматриваю возможность реализации OpenID-провайдера ('OP') с использованием Java + Tomcat / JBoss.

Итак, одна из ключевых особенностей OpenID заключается в том, что

1. Пользователь общается как с OP, так и с RP и проводит сеанс связи с обоими сайтами.
2. OP и RP общаются друг с другом, чтобы убедиться, что пользователь ничего не подделал.

Тема, по которой я не смог найти никакой документации, - это вопрос о том, как правильно реализовать это в ситуации с балансировкой нагрузки.

Общая проблема, которой я опасаюсь, заключается в том, что RP подключается к OP и оказывается на другом сервере приложений, чем пользователь.

Мои вопросы:

• Как правильно с этим справиться?
• Какую библиотеку OpenID "лучше всего" использовать ?

Спасибо.

Answer 1

Общая проблема, которой я опасаюсь, заключается в том, что RP подключается к OP и оказывается на другом сервере приложений, чем пользователь.

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

Балансировка нагрузки с помощью фиксированных сеансов (все последующие запросы от одного и того же клиента поступают на один и тот же сервер) позволила бы сократить количество обновлений кэша.

(Кластеризованные HTTP-сеансы, которые я намеревался использовать изначально, не будут работать, поскольку один и тот же диалог распределен между двумя сеансами:пользователя и приложения.)

Answer 2

На стороне операционной системы единственное состояние, зависящее от OpenID, которое действительно должно быть общим для компьютеров в вашем кластере, - это ассоциации (общие секреты и их дескрипторы).И это довольно легко кэшируется;секрет для данного дескриптора ассоциации никогда не меняется, у них есть четко определенное время жизни, и его не должно быть это многие из них.(Если, возможно, вы не работаете с некоторыми RPS большого объема, которые используют режим без сохранения состояния.)

В зависимости от вашего набора функций и пользовательского интерфейса, у пользователя может быть какое-то другое состояние сеанса, но это не обязательно должно применяться к прямым коммуникациям RP-OP, и вы можете использовать свой стандартный набор трюков.