Difference between revisions of "Criteria for Evaluating User Management Libraries"

From wiki.gpii
Jump to: navigation, search
(Created page with "The GPII is currently pursuing a technology evaluation exercise for selecting a toolkit or library to meet the user management tasks that require to be met for the APCP and LG...")
(No difference)

Revision as of 18:50, 7 April 2016

The GPII is currently pursuing a technology evaluation exercise for selecting a toolkit or library to meet the user management tasks that require to be met for the APCP and LGS deployments. This exercise will be governed by the draft criteria posted to the architecture list at Technology Assessment Criteria (Draft Proposal, 22 March 2016). These criteria will being going through the formal acceptance process for being incorporated into our overall GPII Technical Governance guidelines.

Please contribute additional criteria and further technology options to this page

Functional Criteria

Should allow a user to choose a username/password/email combination, send a validation email containing a link which the system recognises to validate the email. Should operate a session-based login/logout process, and allow the user to reset their password.

{Flesh out these Criteria here}

Technical Criteria

  • Should be able to use a CouchDB database as a backend, storing users in a format compatible with the CouchDB _users database, described at CouchDB Security.
  • Should be capable of sharing this database with other frontend processes which contribute records in other forms - in particular, the use of a "type" field to disambiguate records as required on the CouchDB Designs for Saving and Retrieving Security Data page governing other kinds of security-related records (e.g. OAuth token and client records) required in the GPII.
  • Should allow the UI for the signup/login/logout/reset to be fully reskinnable through the substitution of HTML templates encoded using some commonly operated HTML templating technology.
  • Should expose a RESTful HTTP API which allows the user management process to be operated programmatically from outside the process.
  • Should be configurable to store arbitrary additional fields in the CouchDB user record, which can be sourced from the HTTP request body with which the HTTP API request allocating the user's record is set up.
  • Should be written as a npm-compatible node.js module in JavaScript, with full source code available, GPII-compatible licence, with comprehensive tests.

{Add to these Criteria here}

Currently Known Options

One option is the User Management module incorporated within the LoopBack framework. This module is documented at LoopBack - Managing Users. It's unclear to what extent this module is separable/usable from the overall LoopBack framework. Questions were asked on the Architecture List at Questions and criteria for evaluating LoopBack technology (March 22 2016) to which we require answers.

Another option is the gpii-express-user module which has been developed to meet other requirements within the GPII (the terms dictionary and solutions registry projects). Documentation is included in the top-level readme.

{Add more options here}