[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