OverviewOverview

With NDS Labs v 1.0, we manage rudimentary account information in etcd and support account creation through a simple form. Going forward, we need to support standard account signup and approval workflows, as well as password recovery and management.  We've discussed leveraging Oauth using external IdPs (e.g., Github) as a potential solution. This would allow us to hand off primary identity and password management.

This leaves us with a few decisions:

• Do we support multiple external IdPs or it Gibhub enough, particularly since NDS Labs is targeted at open source developers?
• Do we need to support our own IdP for users that do not have/want to create Github (or other external) accounts?

Whether we have our own IdP or rely on external providers, we will need to provide some sort of approval workflow (unless we want to allow anyone with a Github account to access our services).  If we decide to host our own IdP, we'll need to select from available identity service providers (below) and still need to deal with authentication and authorization into our service (i.e., Oauth support).

Requirements

In priority order:

• Sign-up and approval
• Authentication
• Password management
• Oauth support
• Ability to manage users and groups
• CLI authentication

Recommendations for Beta release

Setting up a local IdP for the Beta release seems like overkill. We expect that the majority of our users will have or be willing to create a Github account for authentication. Optionally, we can add other Oauth providers (e.g., Google, Bitbucket) without needing to install our own IdP. We recommend:

• Implementing Oauth 2.0 support in NDS Labs, with support for one or more Oauth providers
• Implementing a basic approval mechanism to allow us to control who has access to the system

Optionally, we could continue to use our rudimentary scheme, adding password management and account verification:

• Account registration with password hashing
  • NDS-255
  • NDS-213
• Email verification
  • NDS-212
• Password management
  
  • NDS-185

...

After some discussion, we've decided to prioritize the following for the beta release

• Internal account and password management with registration and approval workflows
• Optional Oauth2 support, beginning with Github.

We have decided not to go forward with a full-featured internal IdP (e.g., WSO2). WSO2 seems the most value when we have many users, need to implement permissions, or need to support other auth protocols (e.g., Shibboleth)

Requirements

• User can sign-up (register) for an account
  • NDS-255:  Passwords should be hashed and never returned to client
  • NDS-213: Add email field to wizard
• NDS Labs support an approve/deny a registered user
  • NDS-212: Email verification and account approval email after registration
• User can sign-in using internal credentials:
  • NSD-255: Password should be hashed
• User can reset password
  • NDS-185: User should be able to change their Project login password
• User can recover a forgotten password
  • NDS-438: User can recover forgotten password
• User can sign-up/sign-in with Github
  • NDS-332: 

Oauth

Overview

https://developer.github.com/v3/oauth/#web-application-flow

...

• Login with Github (basic auth)
• Approve account
• Deny account

GUI/API server changes

Oauth support

• Add endpoints to handle oauth requests
  • GET /oauth/providers
    • Returns list of supported providers and info
  • POST /oauth/login
    • provider=github
    • code=AUTH_CODE
    • state=RANDOM_STRING

Registration

• POST /register
  • Send email to configured address abot
  • E-mail address must be unique

Account approval

• Add approval endpoint, only available to admin or with token
  • GET /requests/
  • PUT /requests/user/
    • Approve/Deny
    • Send email to user
    • Template

Account record

• Implement password hashing (bcrypy + salt)
• Add account status (approved unapproved)
• Add change password endpoint (authenticated user)
  • /accounts/user/password
  • POST body:
    • {  "currentPassword": "123456", "newPassword": "this.is.actually.a.much.much.better.password"  }
• Forgot password
  • /accounts/password
  • POST body:
    • {  "email": "email@email.com"  }
      • send a reset password e-mail to the account matching this e-mail address
    • {  "user": "namespace"  }
      • send a reset password e-mail to the account matching this username / namespace
  • Send email to user with link with temporary password that must be changed on login

Candidate SSO Implementations

...