i'm new ldap , trying find best setup implementing multi level security model. need ldap because there several applications used same users , want centralize user management.
with multi level security model mean following. have companies, projects, users , roles.
i want assign roles each combination of company, project , user. combination companya, projecta , usera has rolea combination companya, projectb , usera has not.
i need able ldap search user returns 'records' each combination company, project , role applies.
i know create create 'object tree' in ldap server e.g. setup this
companya | +---- project | | | +----- rolea | | | +---- (attribute) member=usera | +---- (attribute) member=userb | +---- project b | +----- roleb | +---- (attribute) member=usera +---- (attribute) member=userb but contain lot of duplication of objects seems inefficient me.
i'd rather have 4 'lists' of data, companies, projects, roles , users , list contains combinations of these entries. having more experience relational databases, feels more logical. i'm aware setup not logical @ in ldap environment.
i read ldap being able provide access control. using aci's (access control instructions) possible give users access objects. maybe can utilized in manner provide need?
while don't have clear practical understanding of "why's" of setup, can still offer pointers. keep in mind should vet , discuss these ideas others, , make sure understand implications.
it true if have overlapping users (e.g: usera involved both project , project b), there data duplication mentioned. additionally, lead undesirable user experience: if user has 2 accounts, he/she has 2 passwords, must managed somehow. unless such extremity requirement organization, users won't enjoy it. plus, said wanted centralize user management, not further fracture it. ;-)
in situation, can suggest unusual idea.
instead of leveraging complex dit (what might call database or table in 'relational' terms), consider leveraging custom schema instead.
you conceivably create known auxiliary objectclass. prefer using objectclasses because they're static (not fillable attributes, rather "tag" in way).
for example, in case, create aux ocs:
- objectclass: companya
- objectclass: companyb
- objectclass: projecta
- objectclass: projectb
- objectclass: rolea
- objectclass: roleb
a person may have number of these ocs (zero, 1 or of them).
the result single accounts (therefore single passwords) users. each of these users can have whatever combination of ocs see fit, , can configure of clients (e.g: systems , software use ldap server(s)) take advantage of custom filters (queries) require.
the drawback of (typically) schema data not replicated actual data is. so, if have 3 ldap servers, need load schema data onto 3 ldap servers. newer versions of openldap support dynamic configuration, , specific setups, possible replicate configuration engine settings, rare setup i've never seen except in theoretical documentation. in spirit, going assume not option you. correct me if wrong.
regarding aci idea, don't see benefit of using them. acis poorly documented , experimental (also may not compiled build of whatever ldap server you're using).
what want acls (access control lists). can control access specific objects specific people and/or groups. acls better documented , not experimental.
i hope helps. let me know if have questions, etc.
max
Comments
Post a Comment