Domesday/Directory Design: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
The current plan is to make the back-end of Domesday an LDAP directory. This page documents the requirements for the schema etc.
The current plan is to make the back-end of Domesday an LDAP directory. This page attempts to document the requirements and some ideas for the schema.


At several points I say "Gerv suggests"; this is what my research has told me, but I am quite open to being contradicted by those who know more!
At several points I say "Gerv suggests"; this is what my research has told me, but I am quite open to being contradicted by those who know more!
Line 5: Line 5:
===Overall Design===
===Overall Design===


It would be highly desirable if we could design it so that all the security and access control is baked into the schema, such that the web interface code operates only with the permissions of the user currently querying it, and does not even know the cn=root password.
It would be highly desirable if we could design it so that all the security and access control is baked into the schema, such that the web interface code operates only with the permissions of the user currently querying it, and does not even know the cn=root password. This means we could also offer direct LDAP access to people, and it would make the web code much easier to audit for security.


However, as the web interface will update access control data as users change their privacy options, we are going to need access control on the dynamic access control attributes! In other words, users can change the access control for their own data, but not the access control for other people's data.
However, as the web interface will update access control data as users change their privacy options, we are going to need access control on the dynamic access control attributes! In other words, users can change the access control for their own data, but not the access control for other people's data.
Line 40: Line 40:
Some of the most common queries are as follows:
Some of the most common queries are as follows:


* All data (including public tags and private tags added by the user doing the search) for a particular individual, specified by an exact attribute value match - must be particularly fast, as will happen very, very often
* All data (including public tags and private tags added by the user doing the search) for a particular individual, specified by an exact attribute value match (e.g. IRC nick, email address) - must be particularly fast, as will happen very, very often
* All data for all individuals with a particular tag
* All data for all individuals with a particular tag
* All data for all individuals with a certain value or range of values for an attribute or attributes (e.g. everyone in London, everyone on Facebook, everyone whose family name starts with Q)
* All data for all individuals with a certain value or range of values for an attribute or attributes (e.g. everyone in London, everyone on Facebook, everyone whose family name starts with Q)
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits

Navigation menu