Diff for "Teams/Ams-Hackers/Requirements"

Differences between revisions 2 and 3
Revision 2 as of 2016-11-08 12:24:15
Size: 10291
Editor: jonas
Comment: Added requirement to not only cancel but also change payments
Revision 3 as of 2017-01-10 13:31:24
Size: 10446
Editor: jonas
Comment:
Deletions are marked like this. Additions are marked like this.
Line 87: Line 87:
 * CR25: making it possible to provide one-time (or limited time) use e-mail links to set personal data, or similarly, for people who don't have a login.

Overview of the current situation

In general, data is exchanged between the systems using transactional encrypted e-mails. The mails are generated primarily from the web server and sent to the GNUe host for processing, there there are also some emails going in the other direction. The encrypted e-mails are sent via a private VPN. Data is stored in two primary data stores at the moment, LDAP and GNUe (running on separate machines), according to the following:

  • LDAP:
    • Password (hashed, of course)
    • Username
    • Email address (for forwarding of mail)
    • Payment reference
  • GNUe:
    • Address, payment information, and everything else. ("properties", in our terminology)

Roughly speaking, the current systems consist of the following components:

  • The web front-end written as a custom extension to PhpLdapAdmin (PLA) (accepts registrations/donations, create LDAP entries, send requests to GNUe to set/get user properties)

  • CGI scripts to accept Concardis and PayPal notifications for payments (and send this information to the GNUe server)

  • A GNUe application server which holds the data, sends emails with payment reminders, etc
  • An LDAP server which holds basic authentication data
  • Some utility scripts on our MAIL server which accept commands from GNUe and updates the LDAP tree
  • A DESKTOP in the Berlin office which print letters and Fellowship cards
  • (A printer (connected through temporarly SSH tunnel to the database server) at Reinhard's place which also print letters)

Here are some of the processes, with a rough indication of how the various components fit together:

New registration for Fellowship/donation

  1. The new Fellow submits his/her email, name and amount to pay on our web pages [PLA]
  2. A (deactivated) ldap entry is created and the user shown a password [PLA->LDAP]

  3. A <CREATE> mail is sent [PLA->GNUE]

  4. A user entry is created in the Fellowship database and welcome mail sent [GNUE]
  5. User is shown payment information (link to Concardis, Paypal or bank information) [PLA]
  6. If user pays with Concardis or Paypal, those systems sends a notification to us which is received on a webserver [CGI]
  7. Payment information is processed and send by meil [CGI->GNUE]

  8. User is activate with an <ACTIVATE> mail [GNUE->MAIL]

  9. When the user logins (with password from 2.), he/she is asked to set a username (so far we only have email), information of which is sent as a <SET_PROPS> mail together with address information and other properties [PLA->GNUE]

  10. When the username is set in GNUe, this sends a <SET_LOGIN> message to update the ldap accordingly [GNUE->MAIL]

  11. If the user requests to see his/her data, a <REQUEST_PROPS> mail is sent, which causes GNUe to *mail* the information to the user [PLA->GNUE]

New registration for volunteer:

  1. The new volunteer submits his/her email, name on our web pages [PLA]
  2. A (deactivated) ldap entry is created and the user shown a password [PLA->LDAP]

  3. A <CREATE> mail is sent [PLA->GNUE]

  4. A user entry is created in the Fellowship database and welcome mail sent [GNUE]
  5. User is asked to get in touch with a group coordinator [PLA]
  6. A group coordinator verifies that the volunteer should have an account and informs fellowship@fsfeurope.org

  7. Reinhard and/or Jonas manually activates the account in GNUe [GNUE]
  8. User is activate with an <ACTIVATE> mail [GNUE->MAIL]

  9. When the user logins (with password from 2.), he/she is asked to set a username (so far we only have email), information of which is sent as a <SET_PROPS> mail together with address information and other properties [PLA->GNUE]

  10. When the username is set in GNUe, this sends a <SET_LOGIN> message to update the ldap accordingly [GNUE->MAIL]

  11. If the user requests to see his/her data, a <REQUEST_PROPS> mail is sent, which causes GNUe to *mail* the information to the user [PLA->GNUE]

User wants to reset the password:

  1. User submits a request to change password (using email or username) [PLA]
  2. A cookie is set in the user's browser with information [PLA]
  3. An email is sent to the user with a confirmation link [PLA]
  4. The user clicks/copies the link, the cookie is checked to still be valid, and this causes a new password to be generated [PLA]

Change requests

  • CR1: modify/rewrite AMS in a way that it checks against the mailserver/future mail ldap to prevent name collisons and hope that we don't need any name in the future which already has been
  • CR2: handle donations through the same system (requires some changes to GNUe DB to send different mails, etc)
  • CR3: AMS should be translateable
  • CR4: ability to change username (currently a complicated process which require manual intervention)
  • CR5: (to discuss) ability to see own properties on web pages (https likely more secure than unencrypted email, but requires a trusted system and some checks) (discussion point, is it possible, reasonable?)
  • CR6: password reset feature should not depend on cookies (most people seem to fill in the username in one browser, but then open the verification mail from their mail client, which doesn't have the same cookie, which causes the password reset to fail)
  • CR7: password should probably not be set on first create, but by the user when he/she visits the confirmation link sent by mail
  • CR8: we once had the idea of service-level passwords, but we now believe an OpenID/SAML frontend to LDAP will work better and enable untrusted servers to authenticate users against the FSFE ldap.
  • CR9: users registering with a + in their email breaks the current system. It should not :-) (best fix that bug while at it)

  • CR10: should be (reasonably) to extent the properties stored with for instance ssh keys (which we may want for git, svn, etc)
  • CR11: (possibly) integration with mailman (this is a big non-trivial request, so can easily be postponed) so user sees which lists they are subscribed to and can manage this easily
  • CR12: it should be easy to create new templates for sign-up/join landing pages, for instance to have different pages for different campaigns or have different pages for volunteers, for one-time donations and for regular contributors
  • CR13: people who join should be subscribed to the newsletter mailing list (depending on language preference, or opt-out)
  • CR14: we should be able to use SAML/OpenID to authenticate users for services such as OTRS, but in order to be really useful, those services require access to first name and last name (taken from SAML/openID, and by extension from LDAP)
  • CR15: be able to use different passwords for ldap-authenticated services (ie smtp)
  • CR16: store a GnuPG key in the db to use for encrypted e-mail
  • CR17: agree how the "Fellowship" and/or "Fellow" brand should be used and use that consistently throughout all communication
  • CR18: allow users to change their properties without selecting a user name; such a user would not be able to log into any service, but could, for example, still set the address for the donation receipt
  • CR19: allow the user to cancel a recurring payment; this has to be done manually by the FSFE finance team, but at least the interface between the user and that team could be somewhat automatic
  • CR20: to avoid fraud, the system should NOT link a new subscription directly to the payment page but instead include a payment link in the email
  • CR21: allow a user registering as a volunteer a way to express which group they'd like to join etc on the reg form (manual work, but form configuration should be flexible enough to allow this)
  • CR22: provide a backend for coordinators to "manage" the users within their groups, to the extent they can approve volunteer accounts
  • CR23: provide keyrings of uploaded gnupg keys.
  • CR24: provide a way to increase/decrease the recurring donation.
  • CR25: making it possible to provide one-time (or limited time) use e-mail links to set personal data, or similarly, for people who don't have a login.
  • CRxx: [PLEASE ADD MORE HERE]

Work packages

The question here is how to structure this work in a reasonable way so we can work on it piece by piece. This is complicated by the fact that some of the changes we want to make necessitate changes both to GNUE and PLA, and probably LDAP and MAIL as well. So it's not so easy to just break pieces out from the whole and update them separately. However, at the cost of needing to re-do changes later, it's of course possible to resolve some of our immediate needs and many of the change requests we have. We can then approach the other change requests in a structured way afterwards. This is an example of what the work packages could be:

  • WP1. (High-prio) Rewrite PLA using the same functional specification as today, specifically maintaining the interface to GNUE and LDAP unchanged. This could be done without affecting any other system, and would include fixing CR3, CR6, CR7, CR9, CR12, CR19, CR20, CR21, CR24
  • WP2. (High-prio) Complement the LDAP with an OpenID/SAML frontend (work in progress by Julien/Florian), fixes CR8
  • WP3. (Mid-prio) Adapt GNUE to manage donations in the same database as currently used for accounts (needs a bit more elaboration on what changes this entails in WP4), works towards CR2
    • also affects CR5, which is still set out for discussion - I'm not sure it does, ecan you elaborate on it?
  • WP4. (Mid-prio) Adapt PLA (from the rewrite in WP1) to be able to handle donations, fixes CR2, CR18
  • WP5. (Mid-prio) Extend PLA to handle ssh, gnupg keys as well (possibly stored in ldap), fixes CR10, CR15 (schema), CR16 (schema), CR23
  • WP6. (Low-prio) Integrate PLA with mail system, fixes CR1, CR11, CR13
  • WP7. (Mid-prio) Implement suppor for publishing first name/last name through LDAP, should be an optional field, something like "[ ] publish my first name and last name to FSFE's services.", fixes CR14
  • WP8. (Low-prio) Enable service passwords and encrypted e-mail, fixes CR15, CR16 rather split this up --paul
  • WP8. (Low-prio) Enable service passwords, fixes CR15 (frontend)
  • WP9. (Low prio) Enable encrypted e-mail, fixes CR16 (frontend)
  • WP10. (Low-prio) Make a way to change username (CR4)
  • WP11. (Low-prio) Create a frontend for group coordinators to approve volunteer accounts etc