OpenID en una situación de carga equilibrada

Question

Estoy mirando la implementación de un proveedor de OpenID ( 'OP') utilizando Java + Tomcat / JBoss.

Ahora una de las cosas claves acerca de OpenID es que

1. El usuario se comunica tanto con el OP y el RP y tiene una sesión con ambos sitios.
2. El PO y RP se comunican entre sí para asegurar que el usuario no ha falsificado nada.

Un tema que no he sido capaz de encontrar ninguna documentación sobre la cuestión sobre cómo implementar correctamente esta en una situación de equilibrio de carga.

El tema genérico que temo es que el RP se conecta a la OP y termina en un servidor de aplicaciones diferentes que el usuario.

Mis preguntas:

• ¿Cuál es la forma correcta de manejar esto?
• ¿Qué es la 'mejor' biblioteca OpenID para usar?

Gracias.

Answer 1

  

El tema genérico que temo es que el RP se conecta a la OP y termina en un servidor de aplicaciones diferentes que el usuario.

Guardar el estado de conversación en un almacenamiento compartido. Es decir, la base de datos o caché distribuida . Caché sería más rápido, y usted no necesita mucho de la persistencia de todos modos.

equilibrio de carga con sesiones pegajosas (todos consiguiente petición del mismo cliente vienen con el mismo servidor) que reduciría el número de cambios de caché.

(agrupado sesiones HTTP que tenía la intención de consejos inicialmente no funcionarían como la misma conversación se extiende entre dos sesiones:. Usuario y de la aplicación de)

Answer 2

En el lado OP, el único estado de OpenID-específico que realmente tiene que ser compartida entre las máquinas en el clúster es la asociación (los secretos compartidos y sus asas). Y eso es bastante cacheables; el secreto para un mango determinada asociación no cambia nunca, tienen un tiempo de vida bien definido, y no debería ser que muchos de ellos. (A menos que, tal vez, se opera con algunos RPs alto volumen que utilizar el modo sin estado.)

En función de su conjunto de características y la interfaz de usuario, puede haber algún otro estado de sesión para el usuario, pero eso no debería necesitar aplicar a las comunicaciones directas RP-OP y se puede utilizar su bolsa de trucos estándar.