• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Alternative strategies for authenticating against LDAP w/ JNDI

Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all, i�m trying to authenticate users of my application based on username/password against an LDAP server using JNDI. First tried an example from Sun JNDI tutorial, here is the code:
// Set up the environment for creating the initial context
Hashtable env = new Hashtable();
env.put( Context.PROVIDER_URL, "ldap://ldapserver:389/DC=mycompany,DC=com" );
// Authenticate as User and password "mysecret"
env.put( Context.SECURITY_AUTHENTICATION, "simple" );
env.put( Context.SECURITY_CREDENTIALS, "mysecret" );
// Create the initial context
try {
DirContext ctx = new InitialDirContext(env);
// if DirContext is created, no NamingException thrown, everything has gone fine, user is authenticated!!
So far, it worked. Then begun to read about LDAP auth in different newgroups and seems others are authenticating based on user entry attribute lookups in the directory, but have not seen how to match password attribute in the user entry against provided user password.
I�m a bit confused about the whole thing now . Maybe I�m not getting the point here.....
My questions are:
What strategies are there available for authenticating users against LDAP using simple user/pass?
Should I use JNDI, or a propietary LDAP API instead?
If password are stored as a User attribute, are they encrypted? How am I suppossed to compare it with my user�s password? How does my application authenticate itself in the LDAP for searching users and attributes?
Code snippets would be very handy.
Posts: 367
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What you are doing here is a simple bind operation to the LDAP server. (essentially a login operation) You are using the built-in LDAP server authentication. The nice thing about using this style of authentication is that the LDAP server may support more advanced forms of authentication. I coded parts of a CRAM-MD5 authentication mechanism for an LDAP server years ago, and I think that is a fairly standard authentication mechanism.
To put this in relational terms, this is like authenticating to a relational database using database users instead of using the database as a simple password store and retrieving/verifying passwords using SQL. Most relational people would not do that. It opens up your database more than you would want. (everyone can log in to the database) And, of course, user maintenance in a relational database is not standardized in any way.
In the LDAP world, these aren't big issues. LDAP isn't really meant to be a private server. It has a very nice access control model, and having users be able to "login" to the LDAP server (as oppossed to anonymous access) doesn't normally mean anything unless you make it mean something. And admin tools do a very good job of making it mean useful things.
Still, if you aren't actually doing anything with the LDAP server other than authentication, many people prefer to connect to the LDAP server using a pre-defined account and do a compare operation on the password. This is more like a relational database. You have to configure the name/password of the user to connect as to do the check, which means more configuration hassle. But, you also gain the ability to do connection pooling and other
relational type tricks.
Actually, there is one VERY compelling reason for comparing the passwords manually that I didn't mention. When you log in to a web system you normally would use a simple login name. "fred" or "barney" or the likes. An LDAP server knows NOTHING about these names. Your authentication system would have to map this to a DN. (cn=Fred Flintstone, o=Bedrock, c=ZZ) To do this mapping, it is often convenient to connnect to the database and do a simple search operation to find the user. If you are already connected and locating the entry for the operation, why not perform the authentication while you are there?
There's also a step after authentication, called authorization. Once you know that fred is really fred, you still may need to check if he has permissions to access the system. If he is authorized to login, you might want to check if he is an admin or is able to access other parts of the system. The specifics of that are another topic, but I just mention it to say that there are a couple more queries you may need to do on that same connection before you are really done.
I don't have any Java code to illustrate it, but if you can follow C code, you might look at Apache mod-LDAP. This is a spin-off of an LDAP Authentication module for Apache and illustrates a large variety of ways one can use an LDAP server for authentication and authorization.
    Bookmark Topic Watch Topic
  • New Topic