Criteria for Evaluating User Management Libraries

From wiki.gpii
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?
    • Response - These use cases should ideally come from the APCP, where at the minimum we define tiers of users: Human End Users - decomposing public work stations users, AT use cases, developers/admins, service/system accounts, you would want to create a corresponding schema/groups to represent these corresponding roles, authorizations and permissions.
    • For Service/system accounts, consistent with the concept of least privileges, when a component is called, does it require the calling service to authenticate itself, or does it let anything connect? etc. This is all -
  • 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.


One of the libraries that is already part of the GPII stack, passport, already provides support for 2FA, including the ability to integrate Yubikeys, etc.

{Add more options here}

Comparison Chart

GPII-Express StormPath AuthO StrongLoop - Loopback Okta
Type HTTP server library API Framework, HTTP Server Library API Framework API Framework
Security Features HTTP routing, middleware User Authentication

User Authorization

Generation of API Keys

Securing Your REST API with HTTP Basic Authentication

REST API with OAuth 2

Configuring Session Timeouts

Account Verification

Password Reset

Customizing the Views

Caching for Speed

Using Hosted Login

Enterprise connectivity, API Explorer, generators,

client SDKs, websocket microservices

Automated, visual and coding options for creating APIs

Node.js and Java support for creating Microservices

Integrated enterprise grade clustering, management and security for Node.js

Lifecycle and governance for APIs, Products and Plans

Access control over API’s, API Plans and API Products

Advanced API usage analytics

Customizable, self service developer portal for publishing APIs

Policy enforcement, security and control

Directory, SSO,Provisioning, Multi-factor Authentication, In bound Federation
Data Sources None In-memory/file, MongoDB, PostgreSQL,


Security Policy Enforcement NGINX Yes PAP: Policy Authoring Point

PDP: Policy Decision Point

PEP: Policy Enforcement Point

oauth 2.0, SAML 1.0. 1.1, 2.0 SAML Token profiles, Kerberos SPENGO, RADIUS, LDAP, AD, FIPS 140-2 (Level 1- with crypto Modules)

Passport-SAML, AD
AAA - Authentication, Authorization,


RBAC - adminsusers, and developers RBAC - adminsusers, and developers RBAC - adminsusers, and developers
Extensions Express / Connect Middleware Push, File Storage, Passport, OAuth 2.0,

Express Middleware

Support and Community Active - Active - Active -
Licensing Model Consumption based subscription model