Wiki » LDAP Directory Requirements

Directory for users, groups, apps

Requirements for LDAP service.

Possible applications

• User information, authentication
• credentials (groups)

For distribution infrastructure:

• NSS/PAM information on build nodes
• SSH login to build nodes (with password to LDAP, public key, or Kerberos?) - Initially public key, possibly distributed from LDAP by script or config engine
• Any additional data required for file sharing between build nodes and storage nodes (idmap? autofs?) - Mandriva used autofs, and added autofs map entry in LDAP per user, but build cluster file sharing has not been decided.
• Bugtracker (Bugzilla with LDAP support + local fallback) [LDAP parameters]
• VCS repository (svn+http with mod_dav and mod_ldap etc., svn+ssh?, git?) - svn+ssh
• Build system (was the repsys API maintained?)

For web apps:

• Bugzilla or similar
• Forum (phpBB 3, likely) do we want forum accounts in LDAP or not, do we want all forum accounts in LDAP or not, or only contributors who have existing access e.g. bugzilla) - seems no special attributes required => yes * 3, maybe groups/attributes for moderator/admin roles. [LDAP settings]
• Wiki (Mediawiki has LDAP plugin allowing either only LDAP, or LDAP+DB) - no special attributes required [LDAP plugin]
• Mirror data (if we want mirror admins to be able to administer their mirror data?)
• Web-based localisation software? transifex? No transifex documentation regarding user management,but transifex is built on django, which [an LDAP authentication backend] that supports groups with either posixGroup or groupOfNames
• Blogs (wordpress) - LDAP support available for [[1]]
• Something like my.mandriva.com? Serving what purpose => users registering/editing their data
• something like elgg? Maybe crabgrass? Diaspora?

For:

• mailing-list subscriptions? (based on groups?)
• Email aliases?
• GPG public keys?
• IM (e.g. jabber?)

For web-based services

are we considering web SSO technologies (I am not too familiar with the new web SSO frameworks and providers).

[[2]] supports LDAP and Kerberos, mods supporting phpBB3 available.

Misc did mention something about considering a Forge-type software, do we consider one?

Do we have any kind of "load" (e.g. hits for web apps that use basic auth, number of logins for apps with session auth, authenticated svn operations etc.).

Do we want any kind of password policies? While expiry may not be desirable, at least lockout (e.g. 6 hour lockout after 5 failed attempts?) may be a good security measure. Do we want multiple password policies (e.g. contributors with ssh access have more stringent password policies)?

With answers to the above questions we should:

• Be able to verify that we have schema required for all apps we need in short term
• Possibly test LDAP features of some of the software
• Look at any authorization issues in any of the software (e.g., what types of groups are supported)
• Document LDAP configuration requirements (schema, ACLs, indexes, estimate database size, tuning).

For sysadmins who may have operational work for LDAP:

• Configuration file-based configuration, or database-backed configuration (see 'man slapd-config'). Should a sysadmin group have write access to config database in the case of database-backed configuration? Or, should we only allow a local root account with SASL_EXTERNAL over ldapi: ?
• I would prefer at least one replica on another host, but I don't think we need MMR
• Do we need any tools for password resets, password changing, user management?

Types of users / groups

• regular user
• identified team member (1 team = 1 group)
• team leader/representative/backup
• council member
• association member
• board member
• specific roles within teams?
• other?

Basic requirements

About groups:

• a user-group association should have: date registered, date updated, date deleted, reason (or reference, providing a link, should there be a reason for this association)
• we should have a history of these relationships, once they are broken

Unknowns

For web apps, we may need to have front web services for authentication or other requests, using the LDAP as a backend and, depending on the situation, having a separate db for storing user specific info (session, app-specific data, etc.).

SSO could be managed for the whole Mageia infrastructure with this LDAP. We could as well complement it with OpenID (allowing to create a new account easily) or OAuth (within the infrastructure or not). Something to discuss further within the web team, anyway, the LDAP would still be the primary account source.

LDAP proxies to ensure service quality level for separate areas? (one proxy for build system/infra, one for web apps?)

We should agree on a broad, global scheme saying what data should go:

1. in the LDAP (really global stuff)
2. in local apps (some account or specific attributes management)
3. in some tiered database (same but share by several apps).

(as well as having a clear db scheme for CNIL registration).

Solutions

After assessing some available web applications, it was decided that no current solution supported some of the core requirements, so a web application was started, using Catalyst.

Basic requirements:

• Any hardcoded account used by an application should be least-privilege until authenticated as the LDAP identity of the user logging in, after which all access to LDAP should be as the user
• The user interface presented to the user should be sufficiently easy to use for users who don't know what LDAP is
• Users should be able to register themselves, registration should require human validation (e.g. Captcha) and validate the email address
• Users must be able to change their passwords
• Application should be localised

Future features:

• Privileged non-admin users (e.g. "group admin") should be able to add/remove users to/from their group
• admins need to be able to search for users and make changes
• admins need to be able to add privileges to users, some account changes should be defaulted to (e.g. change password policy to be more stringent, automatically assign uidNumber etc.,)
• admins need to be able to search for accounts that have been locked out, and perform password resets easily
• non-account entries should be considered (e.g. sudo rules, autofs maps etc.).

LDIF examples:

Normal (Forum+Bugzilla+Wiki) user:

dn: uid=joe,xxxx,xxxx objectClass: inetOrgPerson uid: joe mail: joe at gmail.com userPassword: {SSHA}xxxxxxxxxxxxxxx

Current Status

Last updated 2010-10-20

An LDAP server has been set up on one of the VMs The testforum phpBB3 instance authenticates against this LDAP installation Registration form satisfying "Basic requirements" above is in svn, being tested, some LDAP config changes to do before deployment LDAP accounts have so far been created for a few contributors manually