Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>While I don't have a clear <em>practical</em> 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.</p> <p>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. ;-)</p> <p>In your situation, I can suggest a somewhat unusual idea.</p> <p>Instead of leveraging a complex DIT (what you might call a database or a table in 'relational' terms), consider leveraging a CUSTOM SCHEMA instead.</p> <p>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).</p> <p>For example, in your case, you could create some AUX OCs:</p> <ul> <li>objectClass: companyA</li> <li>objectClass: companyB</li> <li>objectClass: projectA</li> <li>objectClass: projectB</li> <li>objectClass: roleA</li> <li>objectClass: roleB</li> </ul> <p>A person may have any number of these OCs (zero, one or all of them).</p> <p>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.</p> <p>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.</p> <p>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).</p> <p>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.</p> <p>I hope this helps. Let me know if you have questions, etc.</p> <p>Max</p>
    singulars
    1. This table or related slice is empty.
    1. POwhat LDAP setup to use for multi level security model
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USmaximum ldap
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI like the idea of using object classes as 'tags' but it doesn't solve my problem. I would need 'tags' for combinations of company/project/role which would implicate creating objectClasses for each permutation. This is not a workable solution. About the ACI's, I looked at OpenDJ and ApacheDS but I did not read anything about ACL's, only ACI's. And the ACI setup is pretty complex, especially for ApacheDS. But maybe I missed something. Could you provide some links?
      singulars
      1. PO
      1. USthehpi
    2. COI was speaking in terms of OpenLDAP and not OpenDJ nor ApacheDS (I don't care for those solutions). It may well be that OpenDJ/ApacheDS just call them ACIs at their own discretion. In any case, I only know OpenLDAP.
      singulars
      1. PO
      1. USmaximum ldap
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload