This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
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?
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.
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!
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
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.
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.
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