File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Security and the fly likes Using LDAP vs. Database for authentication/authorization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Using LDAP vs. Database for authentication/authorization" Watch "Using LDAP vs. Database for authentication/authorization" New topic

Using LDAP vs. Database for authentication/authorization

Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

I read Brett McLaughlin's book "Building Java Enterprise Applications: Architecture" a while back and had some questions regarding the use of LDAP that I haven't found any good answers for.
1. How common of a practice is it to use LDAP for authentication and the DB for authorization? (The approach taken in the BJEA book).
2. Is there really any significant gain from separating authentication and authorization? Once a user has been authenticated in LDAP, you still have to hit the Db to authorize. Why not just hit the Db to authenticate and authorize?

Junilu - [How to Ask Questions] [How to Answer Questions]
sajag patel

Joined: Dec 20, 2002
Posts: 7
Why do you need the Datebase to authorize, why not just use the LDAP to do this?
David O'Meara

Joined: Mar 06, 2001
Posts: 13459

We've only ever used completely database or LDAP solutions.
We used a database once because the function-role mapping was very fine grained and was managed as a part of the over-all data architecture.
I'm not convinced it was the right way to go, I still tend to look to LDAP for all authorisation and authentication requirements.
As to possible gains, since LDAP servers should supposedly be optimised for read operations, I'd think separating the A&A responsibilities would be slightly slower on the database side. I can't imagine the load you'd have to be handling to notice the difference though.
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

OK, I got back home and flipped through the BJEA book again. Seems that I remembered wrong: the book's example shows using LDAP for both authentication and authorization. Both are done programatically though. It would have been nice if there were something about JAAS but no such luck. I have more questions but will post in a different thread. Thanks!
Clayton Donley

Joined: Mar 03, 2003
Posts: 27
Exactly, David. Every time I hear about performance as the reason to pick LDAP over database, I typically cringe because most sites and such would probably have a hard time maxing out performance on Oracle, DB2, Mysql, etc... simply with the load generated from user logins (particularly if the user is given a session id of sorts after the initial login).
I think it really comes down to the application and environment. If you're using off-the-shelf products or components that can support LDAP for authentication, you'll probably get a lot more reuse of the LDAP directory. Particularly if you expect that additional applications or components will be deployed later tat could use that same directory, removing the need to somehow provision users in multiple databases.
I will agree that I'd generally keep the user-related authorization information where I keep the user information. Policy information (related primarily to the resource being accessed) can be stored pretty much anywhere, though.
As many of the other threads in the last few days have noted, just because you need user information in the database doesn't mean you can't also have some of that information in a directory if a directory makes sense from an authentication/authorization standpoint and the database will be used for generating reports or associating users with orders, etc...

Clayton Donley, CTO<br />Octet String, Inc.<br />Phone: +1-847-358-9358 ext. 111<br />Email:<p>Author: LDAP Programming, Management, and Integration<br />Manning: <a href="" target="_blank" rel="nofollow"></a><br />Amazon: <a href="" target="_blank" rel="nofollow"></a>
Junilu Lacar

Joined: Feb 26, 2001
Posts: 6529

On second thought and further review of BJEA, I'd like to continue here for a minute...
The BJEA proposes a hybrid approach of using LDAP for authentication of user name and password while using a DB table to store general user information such as User_DN, First_Name, Last_Name, User_Type_Id, Office_Id. The reason given by the author was that LDAP is optimized for reads and authentication is expected to be a fast operation, so LDAP is well suited for this purpose. The DB, on the other hand, is optimized for general access and is more suited to hold the general information that may require both read and write.
In my current project, we are using Oracle's JAAS provider and directory, JAZN and OID, respectively, for authentication and authorization. This has worked well so far but now we have new requirements such as limiting number of login attempts, generating temporary passwords, and expiring passwords. I don't know if these can be handled somehow using LDAP/OID. If it can, then wouldn't this involve writing to LDAP? If we write to LDAP often, wouldn't this negate the advantages of using it for fast reads?
If the new requirements cannot be handled with LDAP/OID, we will probably have to use a DB.
Hence my question about hybrid approaches and whether or not they are common. Is keeping LDAP for reads worth the added complexity if we have to use the DB as well? Or should we just dump the use of LDAP and go DB (or vice versa)?
Any thoughts or advice is welcome.
Sandep Chaturvedi
Ranch Hand

Joined: Aug 20, 2002
Posts: 49
We had a similar requirement to build logic around authentication such number of login attempts etc- We developed elaborate J2EE based API to store and track these information using LDAP.
You can use LDAP to use general user information (such as addresses, company, salary etc) as long as it is not an HR type application but the criteria should be that information is more static and non-transactional.
Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
We use a hybrid approach across multiple applications. We have a central LDAP that does Authentication and Authorization at the Coarse and Mid grain level. Then it is optional whether to put the fine grain Authorization in LDAP or in a DB.
This allows the user to sign-in once and get authenticated into several applications without needing to sign in to each separately.
Then LDAP holds the list of applications that this user is authorized for (Coarse Authorization) and the list of "sub-systems" that he is allowed into within that application.
When it comes down to controling which specific data within the application that the user can access in a function that he has authorization to - the critical applications with high maintenance requirements of user access use a DB(Oracle as a rule). The non-volitile applications or the applications that do not have a need for a DB for any other reason go ahead and use LDAP to store the data restrictions.
For instance, we have an application that is a J2EE front end to a massive DB2 application. There is a legacy MainFrame application that allows update to the application also, but has no fine grained control (or at least not fine enough). This application just hooks up to the existing IMS transactions and uses the existing Mainframe code to update the database, therefore it has no true data of it's own. Yet one of it's greatest values is the fine level of control over what data each user get view or update - so that is kept in the LDAP (We are using Sun One - formerly IPlanet).

"JavaRanch, where the deer and the Certified play" - David O'Meara
I agree. Here's the link:
subject: Using LDAP vs. Database for authentication/authorization
It's not a secret anymore!