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.
> 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.
> 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
>
> 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?
> 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.
> 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?
> Jon
>
>
>
Craig
