[I hope this message is on-topic for this list; if not, please can you
tell me where I can get some advice?]
I am writing a new bit of Mozilla software called Domesday, which is a
community directory:
http://wiki.mozilla.org/Domesday
We hope to scale it beyond 100,000, perhaps up to 1M users eventually.
The aim is to help our community know each other better.
One route is to use a directory for the back end, as directories are
designed to store data about people. I am investigating this. So far, it
seems that the inetOrgPerson objectclass, with another auxiliary
objectClass for a few extra attributes we want, would be the way to go.
However, Domesday has a couple of unusual requirements.
1) Tagging
Firstly, I want to support "tagging". Each user can have a number
(possibly large) of user-defined tags, and it must be possible to search
easily and efficiently for "all users with tag X" or "all users with a
tag which has prefix Y" (so we can support multipart tags, e.g. l10n:es
for Spanish localizers) but also for "all tags for user Z". I anticipate
there being thousands of tags.
At the moment, having read just enough to be dangerous, I think I might
be able to do this using objects under a common dn
(dc=org,dc=mozillians,dc=tags, say) with the groupOfNames objectclass,
with cn=<tagName> and member=<dn> for each member.
Is that the right way to go? Does it allow easy searching for "all tags
for user Z"?
2) Data Access
Domesday is a very privacy-conscious application. While the UI might not
permit quite as much flexibility, I want to support attribute-level
control of data access, where each attribute on a person is associated
with a tag (see above) and only people with that tag can see that
attribute. If there are 100,000 people and maybe 10-20 items of data per
person, that's a lot of access control.
Having read the Access Control documentation:
http://www.openldap.org/doc/admin24/access-control.html
it seems that dynamic configuration would be the only workable choice.
However, I am not entirely sure this can be done or, if it can, that it
can be done in a performant way. It would need a lot of olcAccess
attributes!
So you can see how my two problems are intertwined :-) Can people please
advise me on how best to achieve these two particular goals using OpenLDAP?
Thanks,
Gerv
