Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (athena.apache.org: domain of odeaching@gmail.com
 designates 209.85.161.42 as permitted sender)
MIME-Version: 1.0
Sender: odeaching@gmail.com
Date: Wed, 24 Aug 2011 14:45:16 +0800
Message-ID: 
 <CAPbd=T7LLq-nAiMwreMC_9WON_D=H9nCJvs01_KwLguF_n-KzQ@mail.gmail.com>
Subject: Archiva issue with LDAP (MRM-1488)
From: Deng Ching <oching@apache.org>
To: dev@archiva.apache.org
Content-Type: multipart/alternative; boundary=0015174486c0af5cda04ab3aa7c7

--0015174486c0af5cda04ab3aa7c7
Content-Type: text/plain; charset=ISO-8859-1

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
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

We're planning to use EhCache for this so we can also set a TTL
(time-to-live) for the cached objects. A password change done from the
webapp would flush the user in the cache.
Also, in the logs, we've noticed a number of calls to the LDAP server
(search for users then authenticate) which may not be necessary so we'll
also check if we can improve those.

Any thoughts or comments?

Thanks,
Deng

--0015174486c0af5cda04ab3aa7c7--