what LDAP setup to use for multi level security model

Question

I'm new to LDAP and trying to find the best setup for implementing a multi level security model. I need LDAP because there are several applications that are used by the same users and I want to centralize user management.

With multi level security model I mean the following. I have companies, projects, users and roles.

I want to assign roles to each combination of company, project and user. So the combination companyA, projectA and userA has RoleA but the combination companyA, projectB and userA has not.

I need to be able to do an ldap search for a user which returns 'records' with each combination company, project and role that applies.

I know that I create create a 'object tree' in an ldap server which e.g. is setup like this

companyA
   |
   +---- project A
   |       |
   |       +----- roleA
   |               |
   |               +---- (attribute) member=userA
   |               +---- (attribute) member=userB
   |
   +---- project B
           |
           +----- roleB
                   |
                   +---- (attribute) member=userA
                   +---- (attribute) member=userB

but this will contain a lot of duplication of objects which seems inefficient to me.

I'd rather have 4 'lists' of data, companies, projects, roles and users and another list which contains combinations of these entries. Having more experience with relational databases, this feels more logical. But I'm aware that this setup is not logical at all in an ldap environment.

I read about ldap being able to provide access control. Using ACI's (access control instructions) it is possible to give certain users access to certain objects. Maybe this can be utilized in some manner to provide what I need?

Answer 1

While I don't have a clear practical understanding of the "why's" of this setup, I can still offer some pointers. Keep in mind you should vet and discuss these ideas with others, and make sure you understand the implications.

It is true that if you have overlapping users (e.g: userA is involved with both Project A and Project B), there will be data duplication as you mentioned. Additionally, this could lead to an undesirable user experience: if User A has two accounts, he/she also has two passwords, which must be managed somehow. Unless such an extremity is a requirement for your organization, users definitely won't enjoy it. Plus, you said you wanted to centralize your user management, not further fracture it. ;-)

In your situation, I can suggest a somewhat unusual idea.

Instead of leveraging a complex DIT (what you might call a database or a table in 'relational' terms), consider leveraging a CUSTOM SCHEMA instead.

You could conceivably create something known as an AUXILIARY OBJECTCLASS. I prefer using OBJECTCLASSES because they're static (not fillable attributes, rather just a "tag" in a way).

For example, in your case, you could create some AUX OCs:

• objectClass: companyA
• objectClass: companyB
• objectClass: projectA
• objectClass: projectB
• objectClass: roleA
• objectClass: roleB

A person may have any number of these OCs (zero, one or all of them).

The result is SINGLE accounts (therefore SINGLE passwords) for users. Each of these users can have whatever combination of OCs you see fit, and you can then configure all of your clients (e.g: systems and software that use your LDAP server(s)) to take advantage of custom filters (queries) as you require.

The drawback of this is that (typically) schema data is not replicated like actual DATA is. So, if you have 3 LDAP servers, you need to load this schema data onto the 3 LDAP servers. Newer versions of OpenLDAP support Dynamic Configuration, and with VERY specific setups, it IS possible to replicate the CONFIGURATION engine settings, but this is a rare setup that I've never actually seen anyone do except in theoretical documentation. In that spirit, I am going to assume this is NOT an option for you. Correct me if I am wrong.

Regarding your ACI idea, I don't really see the benefit of using them. ACIs are poorly documented and experimental (also may not be compiled into your build of whatever LDAP server you're using).

What you want are ACLs (Access Control LISTS). You CAN control access to specific objects by specific people and/or groups. ACLs are better documented and not experimental.

I hope this helps. Let me know if you have questions, etc.

Max