Oswaldo Cavalcanti Dantas wrote:
Hello,
I'm developing an EJB to do some operations like password verification
against a LDAP server and creation of users in such server.
For tests, I'm using ApacheDS for LDAP and GlassFish for the EJB
container. Everything works as documented in
http://directory.apache.org/apacheds/1.0/31-authentication-options.html
in the "Sample code with JNDI".
Running as an EJB, I want to use the LDAP as an External JNDI Resource
so the application server can manage a pool for me, but that gives me a
problem when I call the lookup method on the DirContext.
Basically, in GlassFish I set the "JNDI name" to "ldap/example" and the
"JNDI Lookup" to "dc=example,dc=com". In the EJB I can get the reference
to the ldap/example annotating the ctx with "@Resource(name =
"ldap/example")", wich is correctly authenticated and allows me to do
the search for the user.
After finding it and getting it's dn, the "ctx.lookup(dn);" line gives
me a NameNotFoundException where I can see it tried to find a
uid=username,ou=users,dc=example,dc=com,dc=example,dc=com, like it was
appending what I've set for the JNDI Lookup parameter in Glassfish.
As stated in JNDI context API :
"All naming operations are relative to a context. The initial context
implements the Context interface and provides the starting point for
resolution of names."
So if you setup the initial context to point on dc=example,dc=com, every
subsequent operation will be relative to this starting point. If you do
things like a JNDI lookup with this context using "dc=example,dc=com" as
a parameter, then the real DN will be
"dc=example,dc=com,dc=example,dc=com", as the initial context already
points to "dc=example,dc=com".
You have to do a ctx.lookup( dn ) where the DN does not contains the
root context (here, you have to remove the last two elements, ie
dc=example and dc=com).
Doing some string manipulation and comparing the hash password instead
of doing the lookup, I have a working version, but as I understand it
isn't the recomended solution as I'll have to code a lot of
verifications that are already done inside the LDAP server (like
encoding the password with the appropriate algorithm).
So, has anyone encountered a similar problem?
Eveybody using JNDI is suffering the same pain :/ ...
JNDI sucks (TM).
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
