Criteria for Evaluating User Management Libraries

From wiki.gpii
Revision as of 23:21, 18 April 2016 by Bosmon (talk | contribs)
Jump to: navigation, search

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.

Should support the generation and invalidation of tokens

Should allow single sign on between applications\components

- Query: Which part of the GPII workflow will this be useful for? Can we exhibit a user story in which this is useful?

  • Ability to perform RBAC (Role based access) and permissions
    • Can we be clearer? Which GPII use case requires RBAC and permissions?

- Query: As above - can we tie this to a particular GPII user story?

Flexibility to adopt two-factor authentication (In the event APCP decides to introduce the functionality)

{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.
    • As such, should store passwords encrypted with an industrial grade "slow oneway hash" such as PBKDF2 or bcrypt, with appropriate salting
  • Should be capable of sharing this database with other frontend processes which contribute CouchDB 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.
  • Should provided detailed audit controls for SIEM's (Security Information Event Manager) ability to correlate feeds. Including the following
    • Account Logon\Audit Credential Validation. Success, failure or both, Logon\Logoff\Audit Account Lockout, Logon\Logoff\Audit Logoff, Logon\Logoff\Audit Logon, Logon\Logoff\Audit Special Logon, Object Access\Audit Certification Services, Object Access\Audit File System and Object Access\Audit File, Share, Object Access\Audit Registry, Object Access\Audit SAM - Software Assessment Management (Microsoft), Privilege Use\Audit Sensitive Privilege Use. Registry changes.   
    • Query: Can you flesh these out with explanations of terms - e.g. SIEM, SAM, "Audit Certification Services", "Audit File System" etc,. together with connections to use cases that we mean to support - thanks -
      • Done (AO)   

{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. - Reached out to Loopback point person. Please see responses to the questions below.

i) Is LoopBack capable of integrating with any other source of a node HTTP server, or does it always require to create its own? Here are the docs for the standard node http.Server class - - will LoopBack, in some configuration, allow one of these instances to be passed in from the outside?

RESPONSE - Loopback can use any downstream server.

ii) Is LoopBack capable of integrating with any other object instances running within the same node (V8) process - if so, how does it allow these to be located?

RESPONSE - No. You cannot easily inject your own HTTP server into LoopBack

iii) I see that LoopBack, in the standard implementation strategy, relies on code generation via the command-line tool "slc". Under what model is 3rd-party code contributed into these generated artifacts, and what strategy is used to prevent the contributed code being blown away when slc is run again?

RESPONSE - LoopBack does not rely on generated code. It is simply a helper. You can do everything by hand or create your generators. SLC generators based upon Yeoman generators and are OSS as well.

iv) I see that each standard LoopBack application is provided with a hard-coded, autogenerated "server.js" file, of which a sample is here: - are there any permitted variants for this file? if not, how is it possible to freely aggregate multiple LoopBack applications into one, or break them apart into separate deployments as required by the flexible deployment scenarios of the GPII?

RESPONSE - Yes. You can use a different file. This is just how the scaffold works but the framework is fully customizable.

v) Can you use the Loopback managing users features and not use the Loopback framework?

RESPONSE - Yes. But it will require you to create your own sub model from the Loopback Base User, and if needed modify user functions such as login, logout, and password.


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}