On Wed, Aug 24, 2011 at 3:07 PM, Brett Porter <br...@apache.org> wrote:
> > On 24/08/2011, at 4:45 PM, Deng Ching wrote: > > > Hi, > > > > Jev and I are currently working on MRM-1488 (Using Archiva as proxy for > > downloading artifacts is very slow when used with LDAP authentication). > The > > problem we saw here was that for each artifact request, authentication > > happens which in turn results to a call to the LDAP server. > > > > To fix this, we're planning to use an in-memory cache for the LDAP > > credentials. For every authentication request made, Redback will: > > > > 1. look for the user in the cache > > 2. if user is found in the cache, compare credentials > > - if it matches, return successful > > - if it doesn't match, reject it > > The credentials will only be there if you've stored them from a previous > request as you can't get them back out of LDAP. You'll certainly want to > hash this and compare the hash rather that storing the cleartext/base64 > password in memory. > Yep, we'll be storing and comparing the hash :) > > > 3. if user is not found in the cache > > - retrieve user from LDAP server > > - check provided credentials against the retrieved user > > - if it matches, return successful and add retrieved user to the > cache > > - if it doesn't match, reject it > > The current code looks for the user, doesn't get any details, then tries > authentication. This is presumably to check it matches the filter. It'd be > good to check if we can do that ourselves, or as part of the authenticate > call, rather than retrieving the user for the authn step. > > Are you doing this at the redback level, similar to the keys/rbac/users > caching? > Yes > > > > > We're planning to use EhCache for this so we can also set a TTL > > (time-to-live) for the cached objects. > > I think Olivier recently changed the caching strategy in trunk, so we > should stick with that. > Ok, will check that out. Thanks! -Deng
