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 | The current plan is to make the back-end of Domesday an LDAP directory. This page lists the requirements. | ||
===Overall Design=== | |||
We would like to make it so that all the security and access control is enforced by the directory rather than by any client software. | |||
This allows us to expose the directory server to the Internet and offer direct LDAP access so that other people can write clients which consume directory information. | |||
This would also mean that the web interface code can operate only with the permissions of the user currently querying it, and does not even know the RootDN password. This makes it impossible for badly-written web front end code to have a privacy leak. | |||
It would | However, users have the ability to change the privacy controls on their data. So therefore, they must have the ability to update the ACLs. It seems to me (Gerv) that this means we would need access control on the dynamic access control attributes! However, in OpenLDAP at least, these are all stored in the cn=config database rather than in the data tree, and are multiple instances of the same attribute. So it may not be possible to keep the web UI from knowing 'more' than the user using it knows. | ||
We may have to compromise on a system which allows other clients to read and update data, but only the web UI has the special access to alter privacy levels for a particular data item. | |||
===Access Control=== | ===Access Control=== | ||
Access control is based on the tagging system. Each user | Access control is based on the tagging system (see the main documentation). Each user is tagged with a number of tags, and there are a handful (say 3-6; not dozens) of tags which are special - they denote privacy levels (e.g. "trusted", "community-engagement-team"). A user can move any individual item of data about themselves from one privacy level to another. "Public", i.e. world-readable, is a valid privacy level. | ||
The access control complexities come from the facts that: | The access control complexities come from the facts that: | ||
| Line 18: | Line 22: | ||
* Users can individually control the access to their own data items, rather than it being defined centrally or by an administrator | * Users can individually control the access to their own data items, rather than it being defined centrally or by an administrator | ||
* Public tags have their own access control for adding and removing them | * Public tags have their own access control for adding and removing them | ||
* Users should be able to add new tags, but not delete existing ones, unless they are the only person tagged | |||
* Each user has their own private set of tags on other users, which are effectively in their own namespace | * Each user has their own private set of tags on other users, which are effectively in their own namespace | ||
===Attributes=== | ===Attributes=== | ||
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 | 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. | ||
We will need an additional auxiliary objectClass for our own attributes, such as "Call Me" and "Year Started". | |||
===Tagging=== | ===Tagging=== | ||
| Line 32: | Line 35: | ||
See the full explanation of the [[Domesday#Tagging|tagging system]]; familiarity with that is essential for considering this design question. | See the full explanation of the [[Domesday#Tagging|tagging system]]; familiarity with that is essential for considering this design question. | ||
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 helps a great deal. | |||
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 | 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 would be implemented by having a subtree, of the same structure as the public tags tree, under each user's entry. | ||
===Queries=== | ===Queries=== | ||
| Line 55: | Line 58: | ||
===More Ideas=== | ===More Ideas=== | ||
Gerv speculates: might it work if we had several entries for each user, one for each privacy level, under a common root named after that level? You would move attributes between entries based on the privacy level the user assigned. Then when another user did a search, we would just search inside the subtrees which matched the privacy bits that user had. Would that be more performant than having individual access control for each attribute? | Gerv speculates wildly: might it work if we had several entries for each user, one for each privacy level, under a common root named after that level? You would move attributes between entries based on the privacy level the user assigned. Then when another user did a search, we would just search inside the subtrees which matched the privacy bits that user had. Would that be more performant than having individual access control for each attribute? | ||
The difficulty is that inetOrgPerson has a few mandatory fields... we may need a placeholder "not present" value to use. | The difficulty is that inetOrgPerson has a few mandatory fields... we may need a placeholder "not present" value to use. | ||
Of course, this might be premature optimization... | Of course, this might be premature optimization... | ||