Overview

With NDS Labs v 1.0, we manage account information in etcd and account creation through a simple form. Going forward, we need to support standard signup and approval workflows, as well as password recovery and management features. We've discuss leveraging Oauth and external IdPs (e.g., Github).  Using Oauth raises the question of whether we need to run our own IdP for users without Github or other external accounts.

If we rely exclusively on external IdPs, we avoid needing to provide the standard registration/verification workflow as well as password recovery and management. We will still need to deal with authentication and authorization into our service. This likely means implementing an authorization and approval workflow after the user has "signed up" with the selected Oauth provider.

If we decide to host our own IdP, we'll need to select from available open source identity service providers (below) and we will still need to deal with authentication and authorization into our service.

Requirements

In priority order:

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

Use cases:

User can sign-up with Github

• Select "Sign-up" with Github
  
  • User is redirected to https://github.com/login/oauth/authorize
  • User approves access to NDS Labs
  • Account record is created for user, but unapproved
  • NDS Labs support is notified of new account approval
  • Account is approved or denied

Open issues

• Do we need to run our own IdP?
• Is token authentication for CLI OK?

Simple flow

• Sign-up with Github
  • User approves access to NDS Labs
• Create account (unapproved)
  • An account record is created for user

Oauth 2.0 overview

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

• Register service with Oauth identity provider
• Authorization flow 

The Oauth identity provider is the service you will rely on to store user credentials, in our case Github.com. When the user selects to "sign up" with Github.com, the authorization flow begins and the user is prompted to "authorize" our application to access their profile information.  In this case, the user is authorizing NDS Labs. In a later step, NDS Labs will need to authorized the user to access our resources.

Here, NDS Labs is a service provider and Github is an identity provider (in SAML terms). 

Running our own WSO2 IdP, NDS Labs becomes both service and identity provider and can serve as an Oauth IdP for other applications.

Candidate SSO Implementations

Central Authentication Service

• SSO only (no user management)
• No oauth support

Gluu

• So far, haven't been able to get it running

Shibboleth

• SSO only (no user management)
• Requires LDAP or other system

WSO2

WSO2 seems to be the most viable solution for hosting our own IdP. This assumes that we cannot simply rely on external solutions, such as Github.

• Ability to manage users and groups: supported
• Sign-up: supported, requires customization (look and feel)
• Login: supported, requires customization (look and feel)
• Forgot/reset password: requires custom UI development (API available)
• Account approval: requires custom workflow
  • https://docs.wso2.com/display/IS510/Using+Workflows+with+User+Management
• Oauth: supported
• Dashboard – will need to customize user dashboard for IdP

Other options

Sign up with Github

Simply allow the user to sign up with their Oauth account.  This still requires an account approval workflow, but without the need to host our own IdP. 

Steps:

1. Sign-up with Github
2. User is prompted to authorize beta.ndslabs.org
3. Once authorized, an account is created but in an unapproved state.
4. An email is sent to ndslabs support for authorization
5. We authorize/deny the user