The Mozillians.org project has several interesting requirements
- High risk for privacy and legal concerns (Phonebook)
- Innovative data privacy features planned (profile page)
- Potential integration for profiles/identity/SSO/MozillaID across Mozilla web properties
We need to store very sensative user data and provide authentication services. Users will be pending until a community member vouches for them. Pending user's access to other'rs data should should be limited.
Data Privacy Release
After the 1.0 release, an innovative 'data privacy' release will add a per-user, per-attribute privacy preference, which is based on a user's community role.
Any data storage solutions should accommodate these planned features; it should give us building blocks for push the boundaries of easy to use privacy user interfaces.
Solution - LDAP
- Systematic support for Access Control Lists (ACL)
- Mature and open protocol
- Well tested and established open source product - OpenLDAP
- Optimized for heavy read/low write loads that match a Phonebook
- Mozilla already relies on it for mission critical systems
- We are already looking to invest in our LDAP Ops expertise (cross-org win)
- Gerv built Domesday on LDAP
- Easier to test than adhoc NIH solution
- LDAP Directories aren't as sexy as NoSQL datababases
- Current expertise is lacking in Operations and Webdev
Although choosing LDAP isn't sexy, it's the responsible choice for getting a secure, quick to market 1.0 release out.
We'll get LDAP directory training and have designs vetted by an expert, to alleviate some of the risk from the Cons section.
LDAP Training will begin August 29 and will be conducted by Dr. Andrew Finlay
Participants include: Ops:
- Justin Dow, email@example.com
- Rob Tucker, firstname.lastname@example.org
- Peter Bengtsson, email@example.com
- Robert Helmer, firstname.lastname@example.org
I interviewed many engineers in webdev, operations, and externally to brainstorm about off the shelf products that provide per-user, per-attribute data access control. No perfect "off the shelf" solutions were identified, many NIH solutions where invented ;)
A general comment: re-inventing ACL will take extra engineer time, testing time, and security review. Probably 3x to 10x as much time as the LDAP DIT and ACL work. This is fun and enjoyable for the hacker, but isn't the best for time-to-market, nor protecting our community's data.
- Well understood, easy to hire for
- RDBMS are the default backend for Django
- Already in production
- Like Open LDAP, books and education is available
- No robust, general purpose ACL support
- Privacy features will be built in application layer for every feature
- Slower time to market, lower quality from privacy and security POV
- Sexy, easy to recruit talent (new hawtness)
- Flexible schema
- No ACL
- Privacy features built in application layer for every feature
- Another new system for Operations
- Not in production internally
- Not a ton of books, smaller community
See MongoDB, except we have some production experience with it
We can invent a totally new server which is the application layer and data-store.
- Funnest option for devs
- Too many to list