Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-9983

Give DAV-enabled sites a way to cache successful authentications




      Because DAV clients do not understand the concept of secure sessions, the DavServlet will typically end up asking Sakai to re-authenticate a user for every action. When the user data is served by the base implementation, this isn't a terrible amount of overhead. But when authentication is handled by a provider such as Kerberos or LDAP, it's a different story.

      Currently at least one Sakai provider (KerberosUserDirectoryProvider) implements their own authentication cache to help with this. It's implemented as a simple Hashtable whose keys are authentication IDs and whose values are records containing an encoded successful password and a timestamp. There's a setter for the timeout value, which defaults to 5 minutes. When an authentication request comes in, the cache is checked. If the record has timed out or the encoded passwords don't match, the record is removed from the cache and authentication proceeds (and, if successful, a new record is added to the cache). If a good record is there, authentication returns success.

      This is a good start, although it might be good to put some size constraints on the map (by using commons LRUMap, for example). But it doesn't save a lot more work in cases where the authentication provider is also reponsible for returning user data (for example, the Kerberos provider at UC Berkeley), it has to be re-implemented for every new provider (and re-configured by every institution who wants control over authentication caches), and it's not the most efficient spot for a cache check.

      Instead, the most efficient spot to put an authentication cache is above the provider in UserAuthnComponent, BaseUserDirectoryService, or DavServlet code.

      One good reason to put it in the BaseUserDirectoryService is the service's access to two existing userId-to-userData caches. This would make an authentication-to-userId cache about as efficient as possible. Also, the service class is already doing encoded password checks for default base user authentication, and so no new technologies would be brought into the code.

      However, one possible reason to put it in the DavServlet is that DAV's the only thing in Sakai (that I know of) that benefits from such a cache; that way, installations that didn't care about DAV could ignore the whole problem.

        Gliffy Diagrams



              Issue Links



                  Unassigned Unassigned
                  raydavis Ray Davis (Inactive)
                  0 Vote for this issue
                  4 Start watching this issue



                      Git Integration