You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

 Overview

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

Oauth overview

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

Redirect users to request Github access (user approves NDS Labs to access profile):

https://github.com/login/oauth/authorize?client_id=GITHUB_CLIENT_ID&redirect_uri=CALLBACK_URL&scope=&state=RANDOM_STRING&allow_signup=bool

Github redirects back to us:

https://ndslabs.org/login/oauth/endpoint?code=AUTH_CODE&state=RANDOM_STRING

We exchange the AUTH_CODE for a user access token

 

https://github.com/login/oauth/access_token?client_id=GITHUB_CLIENT_ID&client_secret=GITHUB_CLIENT_SECRET&code=AUTH_CODE&redirect_url=&state=RANDOM_STRING

 

 

Github will return a Json object with the Access code and requested user information.

Use Cases

User can sign-in with Github

NDS-330

  • User selects "Sign-in" with Github
  • User is redirected to  https://github.com/login/oauth/authorize
    • User approves access to NDS Labs
    • User is redirected to callback (e.g., ndslabs.org/oauth/github)
  • If no account record exists
    • Account is created for user in unapproved state
    • User is redirected to 403/Forbidden page
    • NDS Labs support is notified of new account approval
  • If account record exists and is not approved
    • User is redirected to 403/Forbidden page
  • If account record exists and is approved
    • User is redirected to Dashboard

NDS Labs staff can approve/deny account

  • NDS Labs staff receives email requesting access approval
    • Email contains links to approve/deny endpoints
  • Select approve
    • Account is marked approved
    • Email sent to user notifying of approval
  • Select deny
    • Account is marked unapproved
    • Email is sent to user notifying of deny?

CLI

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

GUI/API server changes

ndslabs-oaut

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

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?currentPassword=&newPasword=
  • Forgot password
    • /accounts/user/password?email={email@email.com}
    • Send email to user with link with temporary password that must be changed on login

Candidate SSO Implementations

ServiceLicensePlatformNotes
Central Authentication ServiceApache 2.0JavaSSO only (no user management). No oauth support. Can be used for internal SSO across products.
Gluu Java, in theoryInstalled on Centos7, but so far haven't been able to get it running.
IdentityServerApacheMicrosoftRuns on Windows
ShibbolethApacheMultipleSSO only (no user management). Requires LDAP or other user system
WSO2ApacheJavaComprehensive identity provider with support for user management and multiple SSO protocols

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. Features include:

WSO2 example

Start the WSO2 identity server. This is a custom Docker image for NDS Labs with the Github oauth plugin. The IP address will be included in URLs from the service:

docker run -p 9443:9443 -it ndslabs/wso2is:dev 192.168.99.100

Start the Playground example webapp:

docker run -p 8080:8080 ndslabs/wso2is-playground:dev

Open a browser to the admin interface: https://192.168.99.100:9443/carbon/, login as admin/admin

You'll need to register the Playground app as a Github Oauth Application:

This will give you the client ID and secret for the next step

In admin console, select Identity Providers > Add

In admin console, select service providers > Add

  • Name: Playground
  • Inbound authentication > Oauth > Configure
  • This will generate another client/secret (used below)
  • Local and Outbound > 
    • Federated Authentication = github

Open browser to playground: 

Notes

  • It should be possible to map claims (Github profile data into WSO2 data)
  • It is possible to combine local IdP and Github login

See also

https://docs.wso2.com/display/ISCONNECTORS/Configuring+Github+Authenticator

http://wso2.com/library/articles/2016/02/article-how-to-setup-a-wso2-api-manager-store-login-with-google/

https://docs.wso2.com/display/IS500/Identity+Provisioning+Concepts

https://docs.wso2.com/display/IS510/How+To%3A+Login+to+the+Identity+Server+using+Facebook+Credentials#HowTo:LogintotheIdentityServerusingFacebookCredentials-ConfiguringclaimmappingsforFacebook

  • No labels