LDAP Proposal

From Noisebridge
Revision as of 19:28, 29 September 2009 by Dr jesus (talk | contribs) (New page: = Overview = This proposal details how a LDAP or similar system would be deployed to store opt-in directory information for Noisebridge use. The idea is that this would simplify some exi...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

This proposal details how a LDAP or similar system would be deployed to store opt-in directory information for Noisebridge use. The idea is that this would simplify some existing procedures and solve some problems:

  • Treasurer's monthly billing audit.
  • Access control system data for people who opted for nonanonymous access to the space.
  • Centralized authentication database for devices which don't warrant static authentication files. (We currently have four machines in this category and are about to add at least another 7 with the HMI panels.)
  • Centralized preferences database for things like a noisebridge.net vanity address mail forwarder, PCs to drive gear in the shop, lighting, SSH and GPG public keys, etc.

Requirements

  • Be able to store information on both members and non members and differentiate between the two.
  • Keep authentication data on a totally different motherboard than preferences data.
  • High availability. Patching should not incur downtime.
  • Not consume a significant amount of power.
  • Physical access policy should be similar to the existing machines but with auditing so any tampering can be narrowed down.
  • Store hashes in a way no less secure than they are already stored on the cernio machine.
  • Store personally identifiable information in a way no less secure than already stored on officer machines.
  • Must participate in a CA infrastructure so TLS works correctly.
  • Have a cheap/free and easy to deploy miniature test environment for validating proposed changes.
  • Mandatory access controls security policy enforceable by the operating system.

Proposed Trial Implementation

As a starting point to see if all the requirements are fulfilled, a pair of Redhat Directory Server instances on two pogoplugs or beagleboards can be used. This will be used to store preferences data before any authentication data will be hosted. If this pair of machines fulfills all the requirements and is stable, another trial with authentication data can be performed using an additional two machines (for a total of four.)