LDAP authentication
Contents
Goal
All components of the Fellowship infrastructure must authenticate users against a single LDAP server.
Deadline
- End of 2008: set up working authentication for all services
Coordinator
People
- Reinhard Mueller (LDAP installation, patch and sync script)
- Fernanda Weiden (LDAP expertise)
- Cri (I'll take the postfix ldap stuff)
Volunteers are always welcome! Have a look at FellowshipHacks to know how you can help
Status
Last updated: 081025
- An openldap server is running on black.fsfeurope.org (it needs some review)
- The user auth data currently in ez are being synced automatically into ldap
- The wiki already uses ldap for auth; other services not yet
Tasks
This is an overview of the tasks to do for the completion of the project.
You can create a page for a new task using the button below. Just enter the name for the page and it will be automatically created as a subpage of this project page.
Provisional list
- Test LDAP authentication in the services currently being tested
- wiki: DONE, currently working
- blog: DONE, currently testing
- jabber
- postfix mail alias
- Set up replication/fallback strategies to avoid a Single Point Of Failure
Review the LDAP scheme (see Notes -> Requirements)
- Consistent with current and planned services?
Systems involved
- Current systems: none
- Test systems:
- black (ldap server)
- vservers on sulphur (test for new services using ldap)
- Goal systems: see above, unless we move the ldap server away
Notes
Requirements
Fellows deactivation
Reinhard:
When Fellows don't pay their yearly contribution, their account should be deactivated. That is, they should not be able to log in any more, but of course the content they created (in both the wiki and the blog) should remain there. Also, it should be made sure when we change the registration form that a login name that was ever active can't be used any more for a new fellow, as well as a login name that has just registered but not yet paid should not be free for new fellows.
Probably the only way (and most probably the most reasonable way) to achive this is to keep both activated and deactivated users in LDAP, and add some flag that disallows logins. I think this affects the user import to LDAP.
Fellows changing username
Sometimes users wish to change their login name - I remember at least one occasion where this was mentioned here in connection with the transition away from eZ. Do all of our new applications support that?
Other requirements for the LDAP schema
See f-h@ thread 080522
Jabber switch to LDAP
Jabber integration into this is difficult at this time since we have a different set of passwords for our existing Jabber service, which means that in either case, if we integrate Jabber with the usual authentication methods, we need to inform the Fellows in due time that their passwords will change for Jabber.
Postfix switch to LDAP
E-mail relaying to Fellows: once we have an OpenLDAP server, it should be fairly easy to switch Postfix from using the MySQL tables to using LDAP instead, and we can then also enable sending mails via SMTP over SSL, authenticating towards LDAP for the Fellows.
Possible future adoption of OpenID
- Pros of openid:
- Chance to have third parties provide services to Fellows
- Cons of openid:
- Compatibility with current infrastructure
- wordpress?
- moinmoin?
- ...
- Privacy problems (cfr Bernhard)
- Compatibility with current infrastructure
References
Other useful info (webpages, relevant threads on mailing lists etc)
SVN:/Procedures/FellowshipLDAP.wiki