DIT Design -- Handling users in overlapping & changing groups/institutions

Question

Hi Folks-
[My Apologies if there are duplicates, the forum doesn't show any sign of accepting this]
I've been working on a DIT Design to solve a set of business requirements which conflicts with most traditional approaches. I've got some (overly) complicated ideas, but I'm wondering if anyone has encountered a similar situation, and if so did you find a good solution.
Key Requirements:
(1) We have a collection of users from various institutions and groups within them.
(2) (THE MAIN WRINKLE) A certain amount of overlap and movement between institutions is expected (group overlap will be common). A user who is in overlapping institutions or moves between them MUST use a single, shared identity and SHOULD maintain a stable identity (i.e. no DN changes).
(3) Much of the user administration should be decentralized and done at the group level (within each specific institution). An administor of GroupA in Foo Institution should only be able to administer the users in GroupA at Foo, but must be able to control membership within GroupA. Special precautions are permitted to keep a Group-A/Foo administrator from hijacking an arbitrary user by adding the target user to Group-A/Foo.
(4) The number of institutions is expected to be start around 40-50, and could scale to the thousands. The number of people will probably be around 5-20 times the number of institutions. The design should accomodate that scale.
Additional Notes:
(A) I don't see any alternative to keeping any organizational information out of the users' DN's, essentially flattening the users out (I've currently got them all in one container).
(B) I can obviously setup a hierarchy of roles/groups in institutional containers to handle membership and group administrator lists. All Directory Server administration will be done by a small central team and everything can be in containers under a common root suffix.
(C) We currently have the necessary skillsets to develop scripts and programs as needed. But 2 different application families (incompatible foundations -- Java vs. Cobol+Perl) are already scheduled for deployment against this (hopefully more will follow). This means it's not very practical to use one "LDAP Superuser" id and rely on the application to enforce security policies. We really want to put as much of the security into the Directory as possible (calling for individual LDAP admins w/ the appropriate rights), but we can supplement it where we need to.
(D) It looks like I'll have to rely heavily on filters based on the values of particular attributes of each user (whether in ACI's, Filtered Roles, or the like). Unfortunately, I don't see many ways that I can actually build those filters to be dependent on attributes/values of different entries. But I'm still working on that.
(E) Because of the number of institutions (and probable continous growth), writing a master upper-level ACL which has each institution & group explicitly coded is probably unwise due to size and stability. If I have to I could have a helper program custom-code each user's ACL differently and change it as needed. But that doesn't seem like a good solution.
Right now the designs I'm tossing around are calling for combinations of (all/most of) Roles (Filtered & Nested), Groups, CoS Template & Password Policies (yeah, we need those too), Macro ACI's, and a small amount of helper scripts and programs. We're running 5.2 but can probably upgrade to 6.0 if I can cite a good enough reason.
My current design is pretty ugly and complicated but probably attainable. If people are interested enough I'll post a cleansed summary once it's working.
Has anyone tackled anything like this before, and does anyone see any cleaner approach I've missed?
Thanks,
-Scott-

Answer 1

Hi-
We're basically putting all the users in one big container making a flat space.
We then create lots of roles, each of which corresponds to a particular combination of institution, application, and access type/level (the user is implicit as it contains the nsRole). If a user has multiple types of access to an application for a given institution then they will be in multiple corresponding roles.
We have the roles grouped together in a subtree which is divided by institution (and could be further subdivided by application within each institution or placed in the reverse order). But because of the scoping restrictions on nsRole's only a nsNestedRoleDefinition can be placed at this location (using nsRoleScopeDN), the Managed and Filter "working roles" must be in a branch of the tree above all things which will be contained within them (we put it at the top of that naming suffix).
According to the docs, queries will ignore a ldapSubEntry (which all of the nsRoleDefinition's are) unless specifically requested, so the fact that there are hundreds or thousands of roles defined at the top shouldn't matter. However, all of the GUI's I've tried displayed all the roles.
Currently the application code parses the DN of the role names from the user's nsRole entry, NOT the nsRoleDN entry. There end up being a lot of intermediate roles which get ignored. It uses this to determine the access type(s) to be granted. This is really convenient since one query for the user gets everything. However it builds dependencies into the DN format which arguably probably shouldn't be depended on. I've considered defining custom schema attributes which would contain the application/institution/access tuples (which could also be helpful for building nsFilteredRoleDefinition's), but that represents another round of queries and more substantial code changes for the pilot application.
Once in place, the roles can easily be nested and combined in various ways (such as "roll-up" roles containing all users of an application). They can also be used for password policies, CoS templates, and building ACI's. The last should be very helpful in enabling decentralized administration, but that's going to be pretty dependent on your security policy.
An issue with decentralized administration and Managed Roles is that normally anyone who can modify a user's nsRoleDN attribute can place any role in there, which isn't desirable in this environment. I haven't moved forward with the ACI work yet, but it appears that the "targattrfilters" ACI keyword may allow this problem to be solved (possibly in conjunction with Macro ACI's). Using some custom attributes with filtered roles might make this easier.
So, we could have something like this very incomplete LDIF (not checked for errors), only the really important attributes are shown. Also similar entities with the same naming patterns have been omitted.
dn: cn=appusers,ou=webmail,ou=inst01,ou=institutions,o=naming-suffix
objectClass: nsNestedRoleDefinition
nsRoleDN: cn=managed-webmail-inst01-appusers,o=naming-suffix
nsRoleDN: cn=filtered-webmail-inst01-appusers,o=naming-suffix
nsRoleScopeDN: o=naming-suffix
dn: cn=managed-webmail-inst01-appusers,o=naming-suffix
objectClass: nsManagedRoleDefinition
dn: cn=filtered-webmail-inst01-appusers,o=naming-suffix
objectClass: nsFilteredRoleDefinition
nsRoleFilter: (customAppInstAccess=webmail:inst01:user)
dn: uid=jsmith,ou=users,o=naming-suffix
nsRoleDN: cn=managed-webmail-inst01-appusers,o=naming-suffix
nsRoleDN: cn=managed-webmail-inst01-appadmins,o=naming-suffix
dn: uid=jappleseed,ou=users,o=naming-suffix
nsRoleDN: cn=managed-webmail-inst01-appusers,o=naming-suffix
customAppInstAccess: blogger:inst03:user
customAppInstAccess: webmail:inst03:userSo jsmith's nsRole attribute would contain the following values (the ones above the blank line are the main entries, the others are intermediate role to be ignored):
cn=appusers,ou=webmail,ou=inst01,ou=institutions,o=naming-suffix
cn=appadmins,ou=webmail,ou=inst01,ou=institutions,o=naming-suffix
cn=managed-webmail-inst01-appusers,o=naming-suffix
cn=managed-webmail-inst01-appadmins,o=naming-suffixAnd jappleseed's nsRole attribute would contain the following values (the ones above the blank line are the main entries, the others are intermediate role to be ignored):
cn=appusers,ou=webmail,ou=inst01,ou=institutions,o=naming-suffix
cn=appusers,ou=blogger,ou=inst03,ou=institutions,o=naming-suffix
cn=appusers,ou=webmail,ou=inst03,ou=institutions,o=naming-suffix
cn=managed-webmail-inst01-appusers,o=naming-suffix
cn=filtered-blogger-inst03-appusers,o=naming-suffix
cn=filtered-webmail-inst03-appusers,o=naming-suffixIf that doesn't make sense, then you can email me details of what you're trying to do at <[email protected]>, but it may take some time before I can respond.
-Scott-