Following Ignacio's suggestion, I checked out the cvs of 3.3 and tested
the message digest password fucntions again. They are working as (not)
advertised. Not being familiar with Java or Java security, I am still
not sure of the supported message digest algorithms, but, according to
http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.html#AppA,
they include MD5, MD2 and SHA. I tested MD5. I wrote a small app to
generate md5 versions of the plaintext passwords in the users table of
my postgresql 7.1 database.
The html howto on JDBCRealm in the distribution is out of date and a bit
misleading. It documents this entity in server.xml:
<RequestInterceptor className="org.apache.tomcat.request.JDBCRealm"
debug="99" driverName="org.gjt.mm.mysql.Driver"
connectionURL="jdbc:mysql://localhost/authority?user=test;password=test"
userTable="users"
userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="user_roles" roleNameCol="role_name" />
In 3.3, this entity becomes JDBCRealm, and the className attribute
disappears. This is documented in the server.xml file. The howto has
this in the discussion of attributes to the previous entity.
Digest The algorithm used for digest passwords or "No" for plain
passwords, the values can be "MD5", etc... (Optional)
I have used lower-case `digest'; i.e.
digest="MD5"
Then there is the following setion on digested passwords.
Using digested passwords
To use digested password you need to store them digested. To achieve
this, you will need to use the same digest strategies that JDBCrealm
uses to store the passwords, inside JDBCRealm there is a static method
with signature final public static String Digest(String password,String
algorithm) this method is provided as a tool to be used outside
JDBCRealm by an application that want to store passwords readable by
JDBCRealm.
Again, the method is all lower case, i.e.
final public static String digest(String password, String algorithm)
Furthermore, there is a main in JDBCRealm.java which allows the class to
be used as an app to generate the digested passwords. Format is
java org.apache.tomcat.modules.aaa.JDBCRealm -a MD5 passwd1 [passwd2
...]
and the -a argument is your desired algorithm.
Ignacio, I have just put a note in bugzilla. I have a patchfile for the
howto. Where should I send it?
Peter
"Ignacio J. Ortega" wrote:
>
> digested passwords is on 3.3 nightly builds not exactly as yours ..some
> slightly better with MessageDigest and bit more configurable...the
> other can be done but i think it's partiicular need for your app,
> subject of inheritance thought .. in all cases the changes only can go
> to 3.3 ..3.2.x is in bug fix only mode..
>
> Thanks for the feedback..
>
> post the RFE in http://nagoya.apache.org/bugzilla with your code as an
> attach following guidelines on jakarta site
> http://jakarta.apache.org/site/source.html ..
>
> TIA
>
> Saludos ,
> Ignacio J. Ortega
>
> > -----Mensaje original-----
> > De: Christian Hargraves [mailto:[EMAIL PROTECTED]]
> > Enviado el: miércoles 2 de mayo de 2001 16:37
> > Para: [EMAIL PROTECTED]
> > Asunto: JDBCRealm enhancements
> >
> >
> > First off. Is JDBCRealm just an example of what can be done
> > or is it meant
> > for actual use?
> >
> > If it's only meant as an example of how to write a
> > RequestInterceptor, then
> > don't bother to read on, please just respond and tell me so.
> >
> > We need to add some functionality to JDBCRealm that I think a
> > lot of other
> > people might also be able to use.
> >
> > The following modifications are:
> >
> > 1) The option to put in the password encode type -- This is for those
> > companies that encode the password (I think most do).
> > Currently only 'base64' and 'none' are supported. This is
> > done by adding an
> > attribute in the server.xml tag in the RequestInterceptor called
> > encryptMethod.
> > I just used the SecurityTools.base64Decode(password) method
> > to do this.
> >
> > 2) The option of storing the userid as well as the username.
> > -- This is done
> > by adding another optional attribute that states the userid column.
> > This enables user-role table to be queried against the userid
> > instead of the
> > username for those sites that have a lot of users. It also
> > throws the userid
> > in the session for those that need the userid throughout the entire
> > application.
> >
> > Please tell me what you think. We already added the
> > functionality so there is
> > no work for anyone else to do, but to review the code.
> >
> > Christian Hargraves
> >
--
Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
