Domesday/Directory Design

The back-end of Domesday is an LDAP directory. This page lists the requirements for its schema and configuration.

Overall Design

All security and access control should be 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, or authenticate against it.

This also means that the web interface code can operate only with the permissions of the user currently using it, and does not even know the RootDN password. This respect of the Principle of Least Privilege makes it much harder for badly-written web front end code to have a privacy leak or security problem.

Authentication

Users will authenticate against the directory in a fairly normal way, by specifying a unique identifier (uid or email address) and their password. Once authenticated, they will have permission to modify their own data and, if they have the necessary permissions, to view additional data about other people.

Access Control

Access control to user data is based on the tagging system, as described in the main documentation. Each user is tagged with a number of tags, and there are a handful of them (say 3 to 6) which are special - they denote privacy levels. Examples of such tags from the Mozilla deployment might be "mozillian" or "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 hard-coded privacy level which does not correspond to a tag.

The access control complexities come from the facts that:

• Users can individually control the access to their own data items, rather than it being defined centrally or by an administrator
• Each item of user data (attribute) can have different access control (although I guess you could group them into sets based on their level)
• Tags have their own access control system for adding and removing them - some tags are not self-awardable, but require the awarder to have a different tag (the 'bless tag' for that tag)
• 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. (The status of this feature is in question.)

Attributes

See 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, domesdayPerson, for our own attributes, such as "Call Me" and "Year Started". This also gives us flexibility to add additional fields as required.

As noted above, users have the ability to change the privacy controls on each attribute independently. This might suggest that the ACLs will need to be in some way dynamic or rewritten on the fly. However, an LDAP consultant considering this design has told us that it would be possible to implement it in OpenLDAP (which has the most advanced access control facilities) using only static ACLs. Therefore, this is the goal, as using static ACLs would be significantly more robust and safe, and less complex.

Sometimes, legal constraints may require us to prevent certain attributes being set to certain levels (e.g. "address" can't be "public" for minors). If that were implementable at the directory level, that would be great, but we are happy to implement it at the app level. (Minors have easier ways of publicising their home address to the world than firing up an LDAP client.)

Tagging

See the full explanation of the tagging system; familiarity with that is essential for considering this design question.

If a tag has no bless tag, the user is the only person who can award it to themselves. If it has a bless tag, only those with the bless tag can award it, and they can give it to or remove it from anyone.

Some tags come in name:value pairs, colon-separated. The bless tag must apply only to the name. (In other words, there is one bless tag which allows someone to award "l10n:<anything>".) This is to avoid the admin hassle of having to explicitly define e.g. 100 l10n tags, one for each language, all with a bless tag.

(The status of this feature is in question.) Each user has, as it were, their own private set of tags for other users, which can be searched independently of the public ones. It is suggested that this would be implemented by having a subtree, of the same structure as the public tags tree, under each user's entry.

There will need to be controls on the valid character set for tag names - they cannot contain a comma or whitespace, and colon is special (see above).

New Accounts

There are two possible models for the creation of new user accounts:

1. Invitations, and then after acceptance and entry creation it is immediately visible
2. Immediate entry creation, but then finding a voucher is required for it to be visible

It would be helpful to support either method of operation. Either way, there will need to be a "invisible" flag and a field to store the ID of the voucher. We also need to figure out how to delegate creation authority here; anonymous creation of entries needs to be disallowed at the directory level, because of the spam risk.

Queries

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 (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 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)

Updates

The directory will be updated in two ways:

• Users will update their own entry and personal tags (fairly infrequent)
• (The status of this feature is in question.) Users will add user tags to other users (reasonably frequent)

I expect the number of reads to dwarf the number of writes.

Quotes

An external LDAP consultant with significant LDAP ACL expertise has suggested that designing the directory tree structure and ACLs, to the spec given here, would take him around 10 man-days. This includes provision of:

• DIT design
• Object classes and Attribute Types
• ACLs and other OpenLDAP config items
• Test suite (to prove the ACLs work)
• Client Programmers Guide