Integrate with LDAP for company and member directory info

[cdchapman]

Related to #94 and #79. I've put this off for some time, but working on WebID has brought up questions as to the management of directory data of company members:

• Can x509 WebID certificates be managed by a backend key server?
• Does an LDAP ObjectClass exist that can manage historical organizationalRoles and more public profile-ish information (e.g. extended descriptions, work history)?

I'm not sure whether LDAP is the best solution for this, but it might be helpful for members to maintain all of this personal information in one place.

After writing the first comment below, I am adding a few other todos:

• Create a command to update company data.
• Update the company datasource to create Nanoc items from LDIF instead of YAML.
• Create Nanoc itemsrepresentations for member profile photos.
• Update items, layouts, and code to use the LDAP attribute names.

[cdchapman]

This was actually very fruitful. Yes, WebID certificates can be handled by a backend key server, and technically historical roles can be handled, but it might be something to defer to a later issue. All our existing profile needs can be handled by LDAP, including personal photos, which will clear up another issue I hadn't gotten to yet: path_to_photo was not making sense anymore. We should be storing them in LDAP and creating Nanoc items for them.

[cdchapman]

One security question: what are the implications of exposing LDAP DNs in a LDIF file? Not just the tree structure, but specifically the uid attribute. The LDAP servers themselves will not be publicly accessible.

[cdchapman]

Some security related info from RFC 4514:

Distinguished Names typically consist of descriptive information
about the entries they name, which can be people, organizations,
devices, or other real-world objects.  This frequently includes some
of the following kinds of information:

   - the common name of the object (i.e., a person's full name)
   - an email or TCP/IP address
   - its physical location (country, locality, city, street address)
   - organizational attributes (such as department name or
     affiliation)

In some cases, such information can be considered sensitive.  In many
countries, privacy laws exist that prohibit disclosure of certain
kinds of descriptive information (e.g., email addresses).  Hence,
server implementers are encouraged to support Directory Information
Tree (DIT) structural rules and name forms [RFC4512], as these
provide a mechanism for administrators to select appropriate naming
attributes for entries.  Administrators are encouraged to use
mechanisms, access controls, and other administrative controls that
may be available to restrict use of attributes containing sensitive
information in naming of entries.

From RFC 4530 about security considerations for the entryUUID attribute:

An entry's relative distinguish name (RDN) is composed from attribute
values of the entry, which are commonly descriptive of the object the
entry represents.  Although deployers are encouraged to use naming
attributes whose values are widely disclosable [RFC4514], entries are
often named using information that cannot be disclosed to all
parties.  As UUIDs do not contain any descriptive information of the
object they identify, UUIDs may be used to identify a particular
entry without disclosure of its contents.

While I could use entryUUID to distinguish between entries, because I'm fetching the data from LDAP as an intermediate step, the ruby library I am using to parse the LDIF is expecting a DN at the first line of each entry.

On one hand, I don't think that exposing uid attributes and the schema structure of our internal LDAP server is that big of a deal, but on the other hand, it is not too difficult to ask git to ignore the file...