Problems with clustering consumers

[GoogleCodeExporter]

We are running a clustered installation of tomcat servers (solaris boxes)
each of which is using a custom authentication filter requiring openid
authentication. The openid4java build is from Trunk rev 474. Our goal is to
have authentication work in this distributed environment starting on one
server and completing on another. 

Attached is a patch that makes this possible. It contains the following:

1. A fix to the ConsumerManager so that valid associations are not
destroyed until they actually expire, not when they are no longer usable.
Currently, if an association is in its pre-expiration interval, it will be
removed from the underlying store. This means that expiration intervals can
not be set really short with multiple simultaneous authentications occuring
for a given user. 

2. A JDBC version of the ConsumerAssociationStore is added

3. A JDBC version of the NonceVerifier is added

4. A cleanup routine is added to the JdbcServerAssociationStore is added
and called when new associations are generated

These changes were made by Graff Haley (graff.haley@gmail.com) and Andrew
Evenson (proofsrock@gmail.com) if you have any questions. The changes are
currently in use in our server installation at Topia Technologies. 

Original issue reported on code.google.com by proofsr...@gmail.com on 27 Jun 2008 at 4:19

Attachments:

• openid4java-patch.txt

[GoogleCodeExporter]

1. The pre-expiration interval check is indeed better placed in the private 
associate
() method. In a clustered-consumer scenario they could still be used to 
validate the 
signature of potential other incoming AuthResponses; only new AuthRequests 
should be 
prevented from using associations that are about to expire.

In order to keep the functionality of FAILED_ASSOC_HANDLE, the check should be 
however:
+        if ( a != null &&
+                (Association.FAILED_ASSOC_HANDLE.equals(a.getHandle()) ||
+                a.getExpiry().getTime() - System.currentTimeMillis() > 
_preExpiryAssocLockInterval * 1000) )

Association intervals on the other hand are not meant to be set really short; 
what 
makes you want to do so?

Thanks for the patch!

Johnny

Original comment by Johnny.B...@gmail.com on 3 Jul 2008 at 9:16

[GoogleCodeExporter]

4. Thanks for taking care of a TODO item. I've added to the patch a cleanup 
interval, to cut back from the number of delete operations.

Original comment by Johnny.B...@gmail.com on 3 Jul 2008 at 9:28

[GoogleCodeExporter]

Checked in all patches, thanks!

Original comment by Johnny.B...@gmail.com on 9 Jul 2008 at 7:22

• Changed state: Fixed