Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a set of various web applications dedicated to our distributors and partners. Some are standard packages such as Alfresco, others are custom-made web sites.

All are protected by a login. We'd like our users to have a single login for all these apps. Therefore, we are considering setting an OpenLDAP server to serve all these apps authentication requests.

Where should we store application-specific user rights? Such as, who can use app1, who can use app2 and with which role? Should it be stored in LDAP or in the application DB?

In other words, should we keep LDAP simply for basic identity/authentication look up and keep track who can use which app in each app's DB? Or can we store all this info in LDAP (it would make sense)?

TIA for shedding some light.

share|improve this question

For more granular permissions like 'has edit rights on front page' I would keep that at the application level, but for simple 'has read / write access' level permissions I'd implement that in ldap for simplicity sake.

One gotcha to be aware of is the maximum number of groups a user can be associated with on some platforms, therefore I would use a custom name for the app groups membership attribute so that you don't even need to consider this.

share|improve this answer

Use LDAP for authenticating the user and the application DB for determining whether or not that user has rights. You could do it in LDAP alone but the separation has benefits and actually eases management. This is no different to managing user accounts in one area and file/folder permissions in another.

share|improve this answer

Put it all in LDAP, that's what it's for.

share|improve this answer

One thing to point out is while it may be tempting to use Active Directory because of it's LDAP capabilities it may not be the best choice. AD, like many Microsoft products, tend to work great when you stick to Microsoft products, it's when you have to start mixing environments that things get wierd. However to Microsoft's credit they have improved greatly in this realm in the last few years. The biggest challenge you may run into is if you need to make any schema changes to AD to support your applications. Schema changes are not necessarily supported by Microsoft and have the potential to complicate any future AD upgrades. Though in all fairness this is true for any LDAP server, however I would argue it is more common for schema changes to be made on LDAP servers. If you have an existing AD server you can implement a sync operation between your LDAP server (such as Red Hat Directory Server) and your AD server. This can allow you to sync user names, but keep system specific information in each server domain. Yes this does add some complexity to administration but overall it's one of the most flexible approaches.

In the end centralized authentication is governed by this:

"Where do you want your pain?"
share|improve this answer
He says he is planning to use OpenLDAP, not MS AD. – EJP Sep 4 '12 at 8:27
"We are considering" is not the same as "we are planning" or "we will be using." My post is more for the person who searches for this a year from now with similar questions. aka – Red Tux Sep 4 '12 at 13:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.