Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
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 documents the requirements for the schema etc. | ||
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 7: | 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. | 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. | ||
However, as the web interface will update access control data as users change their privacy options, we are going to need | 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. | ||
===Attributes=== | ===Attributes=== | ||
| Line 22: | Line 20: | ||
Gerv suggests: we can use [http://www.openldap.org/doc/admin24/access-control.html#Managing%20access%20with%20Groups OpenLDAP "groups"] and entries with the groupOfNames objectclass to support tags. The groups system is baked into the access control mechanism, which will help a lot, I think. | Gerv suggests: we can use [http://www.openldap.org/doc/admin24/access-control.html#Managing%20access%20with%20Groups OpenLDAP "groups"] and entries with the groupOfNames objectclass to support tags. The groups system is baked into the access control mechanism, which will help a lot, I think. | ||
Each user has, as it were, their own private set of tags for other users, which can be searched independently of the public ones. This might be implemented by having a subtree, of the same structure as the public tags tree, under each user's entry. | |||
===Queries=== | ===Queries=== | ||
| Line 27: | Line 27: | ||
Some of the most common queries are as follows: | Some of the most common queries are as follows: | ||
* All data (including tags) 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 - 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) | ||
| Line 37: | Line 37: | ||
* Users will update their own entry and personal tags (fairly infrequent) | * Users will update their own entry and personal tags (fairly infrequent) | ||
* Users will add user tags to other users (reasonably frequent) | * Users will add user tags to other users (reasonably frequent) | ||
But I expect the number of reads will dwarf the number of writes. Hence using a directory. | |||
===Access Control=== | ===Access Control=== | ||
| Line 42: | Line 44: | ||
The access control complexities come from the facts that: | The access control complexities come from the facts that: | ||
* Each item of user data can have different access control | * Each item of user data (attribute) can have different access control | ||
* Users can individually control the access to their own data items | * Users can individually control the access to their own data items, rather than it being defined centrally or by an administrator | ||
* Tags have their own access control for adding and removing them | * Tags have their own access control for adding and removing them | ||
* Each user has their own private set of tags on other users | * Each user has their own private set of tags on other users | ||
Gerv suggests: access control has to be dynamic. | Gerv suggests: access control has to be dynamic. | ||
===More Ideas=== | |||
Gerv speculates: might it work if we had several entries for each user, one for each privacy level? | |||