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! | |||
===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. | |||
However, as the web interface will update access control data as users change their privacy options, we are going to need more static access control on the dynamic access control attributes! This means users can change the access control for their own data, but not the access control for other people's data. | |||
===Attributes=== | ===Attributes=== | ||
| Line 7: | Line 15: | ||
See [[Domesday#Data_Fields|the main Domesday page]] for a list of data items to be stored, which has been annotated with possible attribute names from inetOrgPerson or elsewhere. The only data which probably cannot be stored in a single entry for a person, or subentries of it in the case of the various service IDs, is the tagging data. | See [[Domesday#Data_Fields|the main Domesday page]] for a list of data items to be stored, which has been annotated with possible attribute names from inetOrgPerson or elsewhere. The only data which probably cannot be stored in a single entry for a person, or subentries of it in the case of the various service IDs, is the tagging data. | ||
Gerv suggests: we will need an additional auxiliary objectClass for our own attributes, such as "Call Me" and "Year Started". | |||
===Tagging=== | |||
See the full explanation of the [[Domesday#Tagging|tagging system]]; familiarity with that is essential for considering this design question. | |||
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. | |||
===Queries=== | ===Queries=== | ||
| Line 23: | 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) | ||
===Access Control=== | |||
The access control complexities come from the facts that: | |||
* Each item of user data can have different access control | |||
* Users can individually control the access to their own data items | |||
* Tags have their own access control for adding and removing them | |||
* Each user has their own private set of tags on other users | |||
Gerv suggests: access control has to be dynamic. | |||