Digest authentication fails with multi-servers

[wsanchez@…]

4/3/07 12:38 PM Cyrus Daboo:

Digest authentication fails when using multiple servers with pydirector.

* STEPS TO REPRODUCE

1. Run a multi-process server with each set to do digest auth.
2. Use the RoundRobin pydirector option to really see this problem in action.
3. Use Safari and navigate to a URI that requires auth.

* RESULTS Safari keeps popping up the authentication dialog.

* REGRESSION This problem occurs because each server instance creates its own "private key" which is used to encode the "opaque" value in the digest challenge. However, with pydirector, the server that sends the digest challenge may not be the same one that receives the client response (e.g. round robin mode in pydirector) so the opaque value in the client response is rejected as the other server instance cannot match it with its private key.

[wsanchez@…]

4/3/07 12:46 PM Cyrus Daboo: Proposal - generate a private key in the "master" setup and pass that on the command line when starting each server instance. Have those use the passed in private key rather than the one they normally generate.

Note this will only work for servers hosted on one machine that are started on that machine. However, if we have a pydirector setup where server instances are on multiple machines, then digest will fail again. The only way around that would be to completely redo the digest implementation by providing a central db of valid client ip/nonce/timeout values that all server instances could share.

4/3/07 1:21 PM Wilfredo Sanchez: We need to do the latter, then, because cross-machine distribution is a requirement.

4/4/07 11:04 AM Cyrus Daboo: A cheap option would be to have a "shared secret" amongst all server configurations. e.g. the Digest authentication config in the .plist could include a "SharedSecret" key that a server admin would be forced to set (i.e. if not present or empty the server would not startup with Digest enabled). We would require that the .plists for all server machines had the same value. That's not that much of an issue because there are several other parameters that need to be kept in sync. We could also include the server's IP in the encoded opaque value, and report a specific error for that if there is a mismatch in the digested value (which would indicate that the "SharedSecret" values possibly do not match).

4/9/07 2:58 PM David Reid: That sounds like an entirely reasonable option.

4/10/07 1:02 PM Cyrus Daboo: Fixed in r1464.

4/11/07 3:25 PM David Reid: Ok, this is all pretty straight forward but .. do we need two options to communicate the secret? And CalDAVOptions is not the right place to generate the SharedSecret. makeService_Combined can do it.

4/13/07 5:43 PM Cyrus Daboo: After further discussion with David on this we have tentatively agreed that we need to do a proper fix for this and use a database to track nonces, nc-counts etc in a similar manner to apache's implementation.

The goal is to define a generic digest db api that can be implemented as a dict in the single server case, or as an sqlite DB which can be shared between multiple server processes on one machine. For the multi-machine case we will require the db be on shared storage - or, later, implement a remote DB storage option.

[wsanchez@…]

What's the difference between Secret and SharedSecret? And why is Secret in the default config file whereas SharedSecret is not? The names here don't tell me much. SharedSecret has comments in config.py, but Secret does not. Let's clean that up if these are to stay.

Let's be sure to put the db solution on a branch for review.

[cdaboo@…]

Fixed in r1512. Now have an sqlite database to track digest nonce/nonce-count values etc and that is shared between all server processes.

David please review.

[dreid@…]

Ok, this all looks pretty good, but the patches concern me. At this point our digest implementation has diverged from Twisted's so much that I don't think it's worth maintaing the patchset. I think pretty much everything can be handled in a subclass with minimal code duplication. It'll be nice to integrate some of these ideas into twisted, but I think it's obvious that time constraints aren't going to make that possible in the near future.

[cdaboo@…]

Code changes moved from Twisted into CalendarServer r1517.

Merged to trunk in r1518.