LDAP for privilege control?

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.

I have done this two different ways and used both at the same time even. First you can make people different ObjectClasses but that can end up being a pain. The other way was to create a groupOfNames with each person in it. I used this two things in combination to give people access to UNIX machines via their ObjectClass and then fine grained control to different web applications via groupOfNames.

You can handle authorization, depending on the underlying server that you are reading via LDAP.

For example in eDirectory, you could specify an object with attributes that users who have access can read the specific attribute value from.

Then you use eDirectory ACL's to allow or deny that.

Use the native ACL model, and then you can easily decide if a user has sufficient rights via LDAP.

Ultimately you need a way to tell one group of users from another and using LDAP/unix you have two options: have a LDAP query which discriminates (&(userName=konrads)(unixLogin=yes)) or using pam_* methods discriminate locally.

I've only had to do something similar once, and we added an attribute to our local schema, and assigned a value for each system that the user was allowed to log into.

Then, in the pam configuration, we had the search string include that they had to have that attribute set appropriately for that machine, so you might have something like:

(&(host:acad1)( ... test to make sure they weren't disabled ... ))

As 'host' was multi-valued, we could just assign as many hosts to the users as needed (and we assigned uidNumbers above 5000 for the LDAP accounts, reserving those below 5000 for applications, sysadmins and other local accounts.)