Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 30152 invoked from network); 14 Jan 2002 17:35:22 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Jan 2002 17:35:22 -0000 Received: (qmail 1333 invoked by uid 97); 14 Jan 2002 17:35:07 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 1271 invoked by uid 97); 14 Jan 2002 17:35:03 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28391 invoked from network); 14 Jan 2002 17:27:01 -0000 Message-ID: <3C430DEE.2030409@yahoo.com> Date: Mon, 14 Jan 2002 08:57:18 -0800 From: obrand User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: tomcat Subject: Proposal for changing RealmBase and implementations X-MIMETrack: Itemize by SMTP Server on PO1/VODUS(Release 5.07a |May 14, 2001) at 01/14/2002 09:03:36 AM, Serialize by Router on PO1/VODUS(Release 5.07a |May 14, 2001) at 01/14/2002 09:19:57 AM, Serialize complete at 01/14/2002 09:19:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N All, I am not in the dev. mailing list but wanted some feedback first on one point I came across in tomcat 4.0.1 I have implemented a Security Provider and a UnixCryptDigest in order to treat passwords on Solaris 8 (we are using OpenLDAP and the PAM framework of the OS). After long research we could not find a way to change the passwords generation (MD5 vs Crypt on Solaris 8). So we are still using Crypt. As I was designing and implementing a clean solution to add such digest, I am facing a problem in the RealmBase where the salt is not taken care of. This salt is not tied to Crypt but can be used for any algorythm. I am proposing the following: 1) Add a getSaltSize and setSaltSize in the RealmBase class. 2) Change the JNDIRealm (and later on the DB Realm, ...) to add a few lines of code: - If there is a digest then - If the saltSize (n) is > 0 then extract the n first bytes from the encoded password, prepend it to the digest (before appending the clear password) 3) Add my Crypt Digest to the source tree of Tomcat 4 or just leave this one out. If it needs to be added, a sub-package security will make sense. Beside this, I was wondering if someone was leading the JAAS effort in Tomcat 4. I have done a lot of work around it (mainly recoded the full framwork compliant with the 1.4 implementation) with a nice XML based JAAS Configuration class. Could you send me some feedbacks on the Salt issue ? If it needs to be added, ... the process to follow in order to add it if needed, .... Cheers Olivier -- To unsubscribe, e-mail: For additional commands, e-mail: