authenticator

The authenticator application that manages user authentication and oAuth authorization (but not resources).

Functionality Required:

• Create User
• User Storage
• Generic Error Handler
• Middleware Layers
  • session handling
• 404 Page Handler
  • 404 Page Template
• Page templating
  • Create page templates package
  • Expose page template interface
  • Implement page template interface
• Register for a new account
  • Create Registration Form
  • Add password strength tool
  • Add username & email address duplicate checker
  • Create api endpoints to check for usernames and email addresses
  • Add captcha (if necessary)
  • Add flash messages for information
• Log into an account
  • Create Login form
  • Add flash messages for information
  • Session Based Flash Messages
• Logout of an account
  • Create Login endpoint
  • Add flash message and redirect to login page
• Reset password
  • Create Reset Password form
  • Add reset password link to login form
• Verify email address
  • Add endpoint to verify email
  • Add template for verification page
• Add CSRF token functionality
• OAuth2 functionality
  • Implement implicit flow
  • Implement token verification endpoint
  • Add a page where users can administer their authorizations
• Create combined login and registration form
• Migrate application to Angular front end
• Add flood controls and rate limiting
• Email Notices functionality
  • Add SendGrid functionality
  • Account Registration notice
  • Password Reset notice
• Add a basic profile page
  • Add functionality to update the user's password
  • Add functionality to update the user's email address
  • Add functionality to update the user's username
• Basic user management interface
  • Create new users
  • Disable user accounts
  • Delete user accounts

All the functionality for user actions should be contained in libuser, but the templates for HTML should be in the main authenticator repository. There should be small pieces of functionality that glue the library to the templates and handle any middleware needs, such as adding captcha.

This system is not meant to handle user profile information. This type of information must live in the applications (partnership site, content engine, etc..) and be exposed in a way those applications see fit. This system only handles the authentication of users and the control of OAuth2 tokens and authorizations.

Requirements

After cloning into your Go Workspace, run go install to grab all the dependencies. If you want to use the database migration scripts, download goose

Setup

If you're using goose setup your db/dbconf.yml file with your db connection:

development:
    driver: mymysql
    open: authenticator/authenticator/authenticator

Reasoning

The NYC Camp Web Properties are implemented as a set of diverse web applications, using many different types of technologies. A traditional authentication and authorization model will not function properly with this type of setup. To allow for Single Sign On and create a strong barrier between authentication server information and app information, we've decided to build this system in Go. The long term goal is to migrate this system into Drupal when possible, but the current Drupal resources are simply not mature enough to handle the needs of this type of system. To handle the needs of both mobile applications, single page applications, and separated resource servers, OAuth2 with Token verification is a necessity. For the time being we don't have the bandwidth to build out a hypermedia API and this type of functionality.