V2 Roadmap

[mcdonnelldean]

All,

Post discussion between myself @mirceaalexandru, @AdrianRossouw and using feedback from others, I have noted down the plan for V2. Our rough estimate for this work stands at about 16 to 23 days, with it most likely falling around 20 days worth of work; a day being a developer day.

Isomorphic client - 4 to 5 Days

• Concorda needs an Isomorphic client that runs in browser and on server
• No dependency on Seneca, it is not required
• Client communicates with Concorda via REST
• Seneca plugin to be created that wraps this client for ease of integration

Concentration on simpler installation - 2 to 3 Days

• Installation options needs to be paired down
• Concorda Dashboard should not be required to use Concorda
• Dashboard is UX over the Client library
• No requirement of Seneca to use Concorda
• Installation should be simple backend server with optional Dashboard as a second process

First class API - 7 to 10 Days

• Concorda's API is actually seneca-auth + some additions being exposed
• API needs to be it's own first class citizen (can proxy seneca-auth for first cut)
• API needs to be a sane RESTful API
• API needs to be clearly documented in it's own right, no deferral to seneca-auth docs

UX needs to match Client functionality - 3 to 5 Days

• There is functionality available on a programmatic level that is missing in UI
• Splash page needs detail added, it's currently blank
• UI needs to handle large numbers of users (this needs to be tested)

V1 focused on making Concorda work well with Seneca based systems and it does this well. Feedback is now focused around greater ease of use over HTTP and with this comes the need for a well defined RESTful API and a first class client.

@AdrianRossouw will be handling Lead duties for this version. Adrian feel free to amend as you gain more context.

[nherment]

Just some additional thoughts on covering some generic security requirements:

logs

• any action taken by any user should be logged (login, logout, create user, renew session, change password, etc.)
• preference for logging to stdout/stderr as it is the unix standard and leaves it to the system to handle logs but direct to files is ok
• do not log sensitive information (email/passwords are sensitive information), username ok.
• log client's IP address
• log timestamp (millisec accuracy)

settings

• Ability to restrict passwords to follow some rules. For example:
  • at least N chars and any 2 of:
    • mix of numbers and letters
    • mix of upper and lower case letters
    • special characters
• Password storage is through a salted hash with the iteration count configurable and updatable during the lifespan of the application
• Sensitive application configuration done through ENV variables and not stored on the file system (eg. DB credentials, cookie secret, etc.)
• cookies must be HTTPS-only in production
• session timeout should be configurable (at least in minutes)

session

• session IDs must be unpredictable (/dev/random based). A hashing algorithm - however long and complex - never adds entropy
• logout must destroy the session token immediately
• only 1 session per user at a given time (login destroys an existing session)
• session cookies have no un-encrypted sensitive information

data validation

• prevent script injections
• validate length of user inputs

Error handling

• server errors don't leak stack traces, SQL error or any sensitive information to the client.

Misc

• CSRF protection
• Automatic disabling of accounts after N unsuccessful logins. Administrator action needed.
• Administrators can never know a user's password. On-boarding can be done through a reset link sent by email
• Reset password can be done by pre-registered users themselves, with configurable expiry of the reset token
• Force users to change password every N days
• Disable users after 180 days of inactivity
• Return generic error when incorrect credentials are entered

Let me know if you have any comment

[mcdonnelldean]

@nherment Could you dump your sample api here too for posterity?

[nherment]

There it is. Might modify it a bit once it matures:

Client

Constructor

var ConcordaClient = require('concorda').Client
var client = new ConcordaClient({
  host: '', // optional for browser
  endpoint: '/auth',
  port: 80, // optional for browser
})

Authentication

client.login()

client.login(username, password)
// HTTP response headers must contain Set-Cookie.
{
  email: 'john.doe@example.com',
  metadata: {
    ...
  },
  sessionToken: '',
  sessionExpiry: ''
}

client.getCurrentUser()

client.getCurrentUser()
{
  email: 'john.doe@example.com',
  metadata: {
    ...
  }
}

client.renewSession()

client.renewSession()
// HTTP response headers must contain Set-Cookie.
{
  sessionToken: ''
  sessionExpiry: ''
}

client.logout()

client.logout()
{}

client.resetPassword()

client.resetPassword(email)
{
  resetTokenExpiry: ''
}

client.setPasswordFromResetToken()

Setting a new password automatically logs-in the user and returns a valid
session cookie & token.

client.setPasswordFromResetToken(resetToken, password)
// HTTP response headers must contain Set-Cookie.
{
  sessionToken: ''
  sessionExpiry: ''
}

for node-app use

client.verifySessionToken()

client.verifySessionToken(email, sessionToken, extendSessionExpiryBool)
{
  email: 'john.doe@example.com',
  metadata: {
    ...
  },
  sessionExpiry: ''
}

Administration API

client.createUser()

client.createUser(email, roles, metadata)
{
}

client.updateUser()

client.updateUser(email, roles, metadata)
{
}

client.disableUser(email) // cannot login/reset password

client.deleteUser(email)