OpenID in a load-balanced situation

Question

Hi,

I'm looking at implementing an OpenID provider ('OP') using Java + Tomcat/JBoss.

Now one of the key things about OpenID is that

1. The user communicates with both the OP and the RP and has a session with both sites.
2. The OP and RP communicate with each other to ensure the user hasn't faked anything.

A subject I've not been able to find any documentation on is the question on how to correctly implement this in a load balanced situation.

The generic issue I fear is that the RP connects to the OP and ends up on a different application server than the user.

My questions:

• What is the right way to handle this?
• What is the 'best' OpenID library to use?

Thanks.

Answer 1

The generic issue I fear is that the RP connects to the OP and ends up on a different application server than the user.

Save the conversation state in a shared storage. That is, database or distributed cache. Cache would be faster, and you don't need much of persistence anyway.

Load-balancing with sticky sessions (all consequent request from the same client come to the same server) would reduce the number of cache updates.

(Clustered HTTP sessions that I intended to advice initially wouldn't work as the same conversation is spread between two sessions: user's and application's.)

Answer 2

On the OP side, the only OpenID-specific state that really needs to be shared among the machines in your cluster is the associations (the shared secrets and their handles). And that's pretty cacheable; the secret for a given association handle never changes, they have a well-defined lifetime, and there shouldn't be that many of them. (Unless, perhaps, you operate with some high-volume RPs that use stateless mode.)

Depending on your feature set and user interface, there may be some other session state for the user, but that shouldn't need to apply to the direct RP-OP communications and you can use your standard bag of tricks.