LDAP for privilege control?

Solution 1:

You can can control access a few ways. RBAC is role based security. Groups are groups of users and roles are groups of access rights. You can map groups into roles or users into roles. In this case, your access rules might read like this:

"Allow everyone in HR to see the HR database" which in implementation would have users group into an LDAP groupOfUniqueNames object. This usually leads to a cleaner organization and most organizations aim for RBAC when starting from nothing. Whether RBAC is fine-grained is another question. For example, roles will control access to an entire document based on groups but won't discriminate down to the paragraph level for you. To some orgs, this is coarse grained.

A more simple approach if this sounds too complicated is to do ABAC (attribute based security) where your app/middle tier/whatever is controlling access by LDAP queries that look like this: "If you have an attribute 'foo' then you can hit the foo application." or "If your foo attribute has the value HR then you can hit the HR application."

The problem with ABAC is that it turns into a real mess. But for some things it's an easy check. For example, I might want people with uid, userPassword and mail attributes to be allowed into a webapp because those are the mandatory attributes my app needs. Then from there my app can look for roles and make more fine grained decisions. Login and nologin is really the queries (login=*) and (!(login=*)) which would allow access based on the existence of a single attribute. This is ABAC and it's usually not reusable and/or edge case scenarios will kill the design. As a contrived example, what if I have a system login for a cron job but I don't really want that system account to log into my app. If I set nologin (like shell to /dev/null or similar) then my cron job doesn't run, if I set it to login then my cron job runs but now a system account has the ability to log into my application needlessly. Create two roles (call them users and system accounts, whatever) and then create a policy that fulfills both requirements.

On an enterprise scale, organizations use identity management (IDM) products to centrally manage, report on and automate these access policies. Automation and reporting comes in handy when you have N systems across N sub organizations in a large company/organization.