----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat User List" <[EMAIL PROTECTED]>
Sent: Thursday, September 06, 2001 4:45 PM
Subject: Re: JNDIRealm working, but, I have a few problems
>
>
> On Thu, 6 Sep 2001, Jonathan Eric Miller wrote:
>
> > Date: Thu, 6 Sep 2001 15:42:52 -0500
> > From: Jonathan Eric Miller <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: Tomcat User List <[EMAIL PROTECTED]>
> > Subject: JNDIRealm working, but, I have a few problems
> >
> > First off, I want to thank Craig for writing up those JNDIRealm
> > instructions. Those worked great. That's exactly the information that I
was
> > looking for.
> >
> > I have JNDIRealm working using both clear-text and digest passwords.
> > However, there are a few problems that need to be resolved before I will
be
> > able to make use of it in our environment. The main reason why I want to
use
> > it, is for single-sign on and there are some issues that are preventing
me
> > from being able to do that.
> >
> > 1. It doesn't support binding as the user rather than as an admin user.
If
> > it did support this, that would solve all the password encryption/format
> > related issues.
> >
>
> This is definitely on the list of things to address. Before 4.0 final
> might be a challenge, though.
Cool, yeah, I just noticed the functional specs that you have in there
regarding "username login" mode. I found it comforting to see that in there
because that is the method that I would prefer to use. I don't really like
the idea of storing an admin password in my configuration file. Also, for
some users, this might not be an option because they not be the directory
administrator. Also, I think it's a good idea to minimize sending the
userPassword attribute over the wire, even if it is encrypted.
I kind of figured that you might not be able to implement that before 4.0
was released. I'm crossing my fingers though. ;-)
> > 2. It doesn't check all userPassword attribute values (some directories
may
> > have more than one value). It should compare each value for a match and
if a
> > match is found, succeed, otherwise fail.
> >
>
> It never occured to me that userPassword would have multiple values :-).
> But that doesn't sound too hard to support.
Yeah, that's what I was hoping. I haven't looked too close at the source
code, but, I'm hoping that just adding a for loop when checking the values
would do it.
The reason it might be helpful at our site is because we are going to be
merging NIS into another directory. Having both passwords in there allows a
user to authenticate successfully using either. Then, when they change their
password for the first time, it gets replaced with a single password. It
might also help having multiple different hashes in there for applications
such as this that do queries against the userPassword field and only support
certain digests.
> > 3. I'm not sure if this problem is specific to iPlanet Directory Server
or
> > not, but, iPlanet prefixes encrypted passwords with the name of a
> > hash/encryption algorithm enclosed in {} followed by the base64 encoded
> > password. For example, the following is what the password "changeit"
looks
> > like.
> >
> > {SHA}BzE/DjIPIsv6Nc/CIFCOs/9FfH4=
> >
> > However, the Tomcat digest application produces what appears to be a
string
> > of hex values like the following.
> >
> > b91cd1a54781790beaa2baf741fa6789
Oops, I posted the wrong value here. It should be the following. The value
above is an MD5 hash.
07313f0e320f22cbfa35cfc220508eb3ff457c7e
> >
> > I think just compares these values (the text reprsentation and doesn't
know
> > to strip off the leading {SHA}), so, it fails. As far as I know the
binary
> > values should be the same because they are both using SHA.
> >
>
> Hmm, those values don't appear to match -- maybe the iPlanet value has
> been Base64 encoded instead of rendered in hex?
Yeah, iPlanet returns "{SHA}" followed by the Base64 encoded SHA hash of the
user's password. I'm not sure how standard this convention is. I think
OpenLDAP may do the same thing? If the password is clear-text, it isn't
prefixed with anything. If it's crypt encrypted it uses "{crypt}". The only
other hashing algorithm it supports is Salted Secure Hash Algorithm which is
"{SSHA}". I wrote a little program to test it.
import org.apache.catalina.realm.*;
import org.apache.catalina.util.*;
public class Test4
{
public static void main (String[] args)
{
try
{
System.out.println(JDBCRealm.Digest("changeit", "SHA"));
System.out.println(HexUtils.convert(Base64.decode("BzE/DjIPIsv6Nc/CIFCOs/9Ff
H4=".getBytes())));
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
The following is the output. As you can see they are pretty much the same.
Not sure why that extra 0000 is on there.
C:\>java Test4
07313f0e320f22cbfa35cfc220508eb3ff457c7e
07313f0e320f22cbfa35cfc220508eb3ff457c7e0000
I haven't figured out why the extra 0000 is at the end.
> > 4. It doesn't support SSL.
> >
>
> Also on the list of things to support -- assuming that the JNDI LDAP
> provider does most of the work.
I think basically, all you need to do is add a line like this just before
you create your DirContext.
h.put(Context.SECURITY_PROTOCOL, "ssl");
Maybe you could add a,
secure="true"
attribute to JNDIRealm (like on HttpConnector), and then if it's present,
set that property?
> > 5. It doesn't support crypt encrypted passwords. crypt may not be the
mose
> > secure, but, it's helpful from the stand point of supporting legacy
systems.
> > Again, if it bound as the user rather than queried for and compared
> > attributes, this wouldn't be an issue. I don't know what kind of impact
that
> > would have on performance, if any, but, it would IMHO be a lot more
secure
> > and more generalized because you could then use whatever password
encryption
> > in the directory that you wanted and not have to worry about it.
> >
>
> I need a Java implementation of the crypt() algorithm that can be licensed
> under the Apache license in order to pull this off. Are there any around?
I found the following link which has some Java implementations of crypt. I
think I'm using JCrypt. It doesn't seem to list the licensing, but, it says
that it's based on the C source from Eric Young. Isn't he the one that
started OpenSSL or something? I wonder if that says anything about the
licensing?
http://www.dynamic.net.au/christos/crypt/
Thanks, Jon
> > Jon
> >
> >
> >
>
> Craig
