LDAP Proposal

From Noisebridge
Revision as of 19:35, 29 September 2009 by Dr jesus (talk | contribs) (→‎Example Use Cases)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview[edit]

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. Anonymity is a concern for the system design and it should be completely ignorable by people who wish to remain anonymous.

  • 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.


Example Use Cases[edit]

  • Publish public keys using a public LDAP server with certifiable SSL certificate.
  • Have the space auto-vote on what music to play based on the stored preferences of the people who have opted for nonanonymous access to the space.
  • Federate with other hacker spaces so we can trade access to each other's computing resources.
  • Allow the IRC bots to do the right thing with regard to user access.
  • Have the HMI panels display "tell" alerts from noisebot and the panel interface when the system detects a nonanonymous user using an RFID fob to enter the space.

Requirements[edit]

  • 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[edit]

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