LDAP Proposal - Revision history

Dr jesus: /* Example Use Cases */

2009-09-30T02:35:46Z

Example Use Cases

← Older revision		Revision as of 19:35, 29 September 2009
Line 19:		Line 19:
	* 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.		* 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 ~~which aren't as public~~ so we can trade access to each other's computing resources.		* 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.		* 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 =		= Requirements =

Dr jesus: /* Overview */

2009-09-30T02:33:37Z

Overview

← Older revision		Revision as of 19:33, 29 September 2009
Line 1:		Line 1:
	= Overview =		= 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:		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.		* Treasurer's monthly billing audit.
Line 10:		Line 10:

	* 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.		* 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 ==

			* 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 which aren't as public 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.

			*

	= Requirements =		= Requirements =

Dr jesus: 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...

2009-09-30T02:28:27Z

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

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