Authentication and user management for OpenQuake

= Authentication =

Authentication is any process by which you verify that someone is who they
claim they are [1].
Requirements:
    - we need to authenticate OpenQuake users irrespective of the client
      they are using (e.g. web UI or command line)
    - we need to facilitate the addition, removal and suspending of
      users
    - it shall be possible to organise users into organisations
    - it shall be possible to capture the following data per user:
        title, first name, last name, email, phone number, instant
        messaging (IM) account name, IM provider
    - it shall be possible to capture the following data per
      organisation:
        name, postal address, http URI
    - it shall be possible to capture the following data per
      organisation:
        name, http URI (django only supports a name)

== User stories ==

This applies to all OpenQuake clients whether command line driven or GUI.

As the administrator for a given OpenQuake installation I want to be able to
  1 - add one or more organisations
  2 - remove one or more organisations
  3 - modify one or more organisations
  4 - add one or more users
  5 - remove one or more users
  6 - modify one or more users
  7 - suspend/disable one or more users
  8 - reset the password of one or more users
  9 - list all users for a given organisation

As an ordinary OpenQuake user I want to be able to
 10 - change any of my data including the password
 11 - list all users that belong to my organisation

= Notes =

 N1 - a user belongs to one organisation, the latter may have 1+
      users
 N2 - an organisation may not be deleted unless all its users
      are deleted
 N3 - each organisation must have 1+ administrative users
 N4 - we will add a default "openquake" user when the python-oq package is
      installed.

= Questions =

 Q1 - what shall be done with a user's artefacts (source models,
      calculation results etc.) when he is deleted
 Q2 - django authentication is well documented [2] and supports user profiles
      [3], how does the GeoServer/geonode authentication work and how do we
      plug into it?
 Q3 - should we support authentication irrespective of the OpenQuake frontend
      type?
 Q4 - how do we support authentication irrespective of the OpenQuake frontend
      type? Should we e.g. always make use of the django auth bits and add
      what we need beyond that?
 Q5 - how will the global components plug into the OpenQuake
      authentication system and vice versa?
 Q6 - how would we extend the authentication system to cover a restish
      OpenQuake API?

= References =

[1] http://httpd.apache.org/docs/1.3/howto/auth.html
[2] https://docs.djangoproject.com/en/dev/topics/auth/
[3] https://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users