Bring production up to date with master

.eslintrc.json

@@ -0,0 +1,6 @@
+{
+  "extends": ["eslint:recommended", "google"],
+  "rules": {
+    // Additional, per-project rules...
+  }
+}

CODE_OF_CONDUCT.md

@@ -0,0 +1,15 @@
+# Community Participation Guidelines
+
+This repository is governed by Mozilla's code of conduct and etiquette guidelines. 
+For more details, please read the
+[Mozilla Community Participation Guidelines](https://www.mozilla.org/about/governance/policies/participation/). 
+
+## How to Report
+For more information on how to report violations of the Community Participation Guidelines, please read our '[How to Report](https://www.mozilla.org/about/governance/policies/participation/reporting/)' page.
+
+<!--
+## Project Specific Etiquette
+
+In some cases, there will be additional project etiquette i.e.: (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html).
+Please update for your project.
+-->

Makefile

@@ -0,0 +1,29 @@
+URI		:= auth-dev.mozilla.auth0.com
+CLIENTID	:= 
+CLIENTSECRET	:=
+
+all:
+	@echo 'Available make targets:'
+	@grep '^[^#[:space:]].*:' Makefile
+
+python-venv: venv
+venv:
+	$(shell [ -d venv ] || python3 -m venv venv)
+	echo "# Run this in your shell to activate:"
+	echo "source venv/bin/activate"
+
+install:
+	pip install -r requirements.txt
+
+
+deploy-local:
+	# Requires a credentials.json file to be present and valid
+	# Useful for local tests
+	uploader_rules.py -r rules
+
+deploy:
+	@echo "Deploying to $(URI)"
+	uploader_rules.py -r rules -u $(URI) -c $(CLIENTID) -s $(CLIENTSECRET)
+
+
+.PHONY: venv all install deploy

README.md

@@ -4,12 +4,103 @@ You can find more information about Auth0 at https://www.auth0.com
 
 The rules are snippets of javascript code running as webtasks (https://www.webtasks.io), which modify the authentication flow of users in Auth0.
 
-See also: https://github.com/auth0-samples/github-source-control-integration
-
 ## Branches
 
 `master`:
 The master branch is used for development of rules and are auto-deployed on https://manage-dev.mozilla.auth0.com/
 
 `production`:
 /!\ The production branch uses merges from the master branch and are used for production. These are auto-deployed on https://manage.mozilla.auth0.com/
+
+## Deployment & CI
+
+Rules are deployed with `auth0-ci` <https://github.com/mozilla-iam/auth0-ci> after CI has completed.
+For testing, this looks like this:
+
+```
+$ python3 -m venv venv
+$ source venv/bin/activate
+$ pip install -r requirements.txt
+$ uploader_rules.py <args>
+```
+
+## Development
+
+How do I know which nodejs modules are available to me?
+
+At this time Auth0 runs nodejs8. The module list that is cached inside webtasks is listed here:
+https://auth0-extensions.github.io/canirequire/#rsa
+
+### Style
+
+The primary goal is to follow the style of the [Auth0 example rules](https://github.com/auth0/rules/tree/master/src/rules).
+This appears to follow the [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)
+in some ways as there are trailing semi-colon characters. In other ways the 
+Auth0 rules do not follow the Google style as some contain [`var` declarations](https://google.github.io/styleguide/jsguide.html#features-use-const-and-let)
+Try to follow the Google style in the Mozilla rules in this repo.
+
+### Development cycle
+
+This is the cycle today. In the future we hopefully add CI driven tests. 
+This cycle could be improved.
+
+Please note that for any large change (i.e. anything but a single rule change), it is recommended to backup the current rules before deploying. You can do this by following the run-book at https://mana.mozilla.org/wiki/display/SECURITY/Create+and+reload+auth0+rules+backup
+
+1. Write a rule in your local fork of the repo
+2. Run `uploader_rules.py -r rules` to deploy the uncommitted rule to auth0-dev
+3. Do manual testing in auth0-dev to determine if the rule does what you want
+4. Iterate steps 1-3 until you have a rule that works
+5. Remove the new rule from auth0-dev. This could be done by checking out 
+   master (which doesn't have the rule) and again running `uploader_rules.py -r rules`
+6. Push your branch to your fork and create a PR with your new rule, requesting 
+   a review of the PR.
+7. Someone reviews the PR, either suggesting changes or approving
+8. Merge the PR
+9. CI deploys the PR to auth0-dev
+   * This CI runs in AWS CodeBuild in the `mozilla-iam` (320464205386) AWS
+     account in the `us-west-2` region in the AWS CodeBuild project
+     `auth0-deploy-stage`.
+   * The CodeBuild project follows the [`buildspec.yml`](buildspec.yml) which
+     calls the [`Makefile`](Makefile) which calls the 
+     [`uploader_rules.py`](https://github.com/mozilla-iam/auth0-ci/blob/master/uploader_rules.py)
+     tool which is installed from the [`auth0-ci`](https://github.com/mozilla-iam/auth0-ci)
+     project.
+10. Manually test again in auth0-dev to validate that the rule works. This is 
+    the stage to do more thorough testing as this is the last step before
+    production deployment
+11. If testing validates the rule is good, create a second PR from `master` to
+    `production`, requesting review and referencing in the text of the PR the
+    first PR which contains the initial review. Ideally the changes in the first
+    dev PR and this prod PR will be the same and the reviewer can leverage
+    the dev PR's review. If that's not the case a new thorough review would be
+    needed.
+12. During change window, merge PR.
+    * As of September 2019 this won't trigger CI to deploy to prod as it's not been
+      setup
+    * Instead, manually deploy to prod using [`uploader_rules.py`](https://github.com/mozilla-iam/auth0-ci/blob/master/uploader_rules.py)
+     from the [`auth0-ci`](https://github.com/mozilla-iam/auth0-ci) project.
+13. [Test in prod](https://mana.mozilla.org/wiki/display/SECURITY/Auth0+manual+testing) to make sure everything works and rollback if it doesn't.  
+
+## Known Issues
+
+### Auth0 Rule Web UI jshint configuration
+
+The Auth0 web UI where you can view and modify rules, for example at
+https://manage-dev.mozilla.auth0.com/dashboard/pi/auth-dev/rules
+has a jshint built in which isn't aware that Auth0 rules are run under
+Node version `8.11.4` and as a result shows errors for things like
+`require` and `let`. To work around this add this to the top of your rule
+
+```
+/*jshint esversion: 6 */
+```
+
+### Auth0 Rule Web UI save button
+
+The Auth0 web UI where you can view and modify rules, for example at
+https://manage-dev.mozilla.auth0.com/dashboard/pi/auth-dev/rules
+when you click the `Save` button, a green banner saying
+`The rule script has been saved` shows up. The content however won't
+always be saved and the `Save` button won't always turn from blue to
+gray. If waiting on the page for the async save to complete isn't working
+you can click the `Save` button a second time.

buildspec.yml

@@ -0,0 +1,14 @@
+version: 0.2
+
+env:
+  parameter-store:
+    CLIENTID: "/iam/auth0-deploy/stage/AUTH0_RULE_DEPLOY_CLIENTID"
+    CLIENTSECRET: "/iam/auth0-deploy/stage/AUTH0_RULE_DEPLOY_CLIENTSECRET"
+    URI: "/iam/auth0-deploy/stage/AUTH0_URI"
+phases:
+  build:
+    commands:
+      - make install
+  post_build:
+    commands:
+      - make CLIENTID=${CLIENTID} CLIENTSECRET=${CLIENTSECRET} URI=${URI} deploy

manual/README.md

@@ -1,6 +1,41 @@
-## manual
+# manual
 
 This area is for manual-deploy of specific files, when auth0 does not yet support auto-deployment.
 Ideally these should be moved to directories that can auto-deploy the code/templates/etc. in the future.
 
 This mean any change to files in this directory will need to be manually mirrored in the auth0 setup.
+
+## social-fxa.js : Firefox Accounts Custom Social Connection
+
+This adds support in Auth0 for Firefox Accounts (FxA) as an [Auth0 Connection](https://auth0.com/docs/applications/connections)
+(aka IdP).
+
+### How to deploy the code
+
+1. Log into the Auth0 management UI
+2. Click `Extensions` in the left hand list of sections
+3. In the Extensions list, click `Custom Social Connections`
+4. Delegate permissions to this Extension when prompted
+5. In the new `Custom Social Connections` window click `Firefoxaccounts`
+6. Copy and paste the `social-fxa.js` code into the `Fetch User Profile Script` textbox
+
+### How to manage the service
+
+***Attempting to manage this extension with Firefox will not work. You must use Chrome or fake a Chrome User-Agent***
+
+![Chrome Logo](https://www.google.com/chrome/static/images/chrome-logo.svg)
+
+1. Log into the Auth0 management UI
+2. Click `Extensions` in the left hand list of sections
+3. In the Extensions list, click `Custom Social Connections`
+4. Delegate permissions to this Extension when prompted
+5. In the new `Custom Social Connections` window click `Firefoxaccounts`
+6. Click the `Apps` tab
+  * From here you can affect which [Auth0 Applications](https://auth0.com/docs/applications)
+    will have Firefox Accounts enabled or disabled as an allowed Auth0 Connection type
+  * The grey and green switches to the right of the list of applications can be clicked to change
+    whether Firefox Accounts is enabled.
+
+## passwordless.html
+
+## maintenance.html

manual/maintenance.html

@@ -0,0 +1,28 @@
+<!DOCTYPE html>
+<!--
+This page is used in case the login page fails to display and also fails to display any error or warning.
+This is for EMERGENCY ONLY.
+It is meant to be used as such (or similar):
+
+$ xclip maintenance.html # or open this in your text editor, select-all and copy
+Go to https://manage.mozilla.auth0.com/#/login_page
+Paste and save.
+-->
+<html lang="en">
+  <head>
+    <title>Mozilla Login - Maintenance</title>
+    <meta name="viewport" content="width=device-width, initial-scale=1">
+  </head>
+  <body>
+    <h1>Maintenance mode</h1>
+    <p>
+    We are currently experiencing an issue &amp; working hard to resolve it. Please try to login again in a few minutes.
+    </p>
+    <br/>
+    <p>
+    For emergencies, you can request help via <a href="mailto:moc@mozilla.com">moc@mozilla.com</a>, on IRC channel <a
+    href="irc://irc.mozilla.org/moc">#moc</a>
+    or Slack channel <a href="https://mozilla.slack.com/">#mozsm-all</a>
+    </p>
+  </body>
+</html>

manual/social-fxa.js

@@ -0,0 +1,71 @@
+// This is the Fetch User Profile Script for FxA
+// Note the `acr_values` parameter, which requires AAL2 authenticator assurance level
+// (https://pages.nist.gov/800-63-3/sp800-63b.html)
+// Authenticator Assurance Level 2: AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
+// We'd also be fine with AAL3 of course, though FxA supports up to AAL2 at this time.
+
+// Well-known URLs:
+// Prod: https://accounts.firefox.com/.well-known/openid-configuration
+// Stage: https://accounts.stage.mozaws.net/.well-known/openid-configuration
+// Dev: https://oauth-latest.dev.lcip.org/.well-known/openid-configuration
+//
+// Example:
+// Authorization endpoint: https://oauth-latest.dev.lcip.org/v1/authorization?acr_values=AAL2
+// Token endpoint: https://oauth-latest.dev.lcip.org/v1/token
+// scopes: openid profile
+// Note that as per above, using the authorization parameter `acr_values=AAL2` will enforce authenticating accounts with 2FA only
+
+function(accessToken, ctx, cb) {
+  // Auth0 already verified the id_token and it's signature at this stage
+  // See docs at https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Firefox_Accounts/Introduction
+  // See also https://github.com/mozilla/fxa-oauth-server/issues/519#issuecomment-367196241 for information on fields
+  // Note that we assert this email is verified by FxA, though we do not check `amr` contains `email`. This is because
+  // We currently assert `email_verified` to be true if it has ever been verified, not if it's "just been verified"
+  var jwt = require('jsonwebtoken');
+  var id_token = jwt.decode(ctx.id_token);
+
+  // Request additional profile info, such as picture, locale, etc.
+  request.get('https://profile.stage.mozaws.net/v1/profile',
+    {
+      'headers': {
+        'Authorization': 'Bearer ' + accessToken,
+        'User-Agent': 'MozillaIAM-Auth0'
+      }
+    },
+    function(e, r, b) {
+      if (e) return callback(e);
+      if (r.statusCode !== 200) {
+        return cb(new Error('Failed to fetch user profile. StatusCode:' + r.statusCode));
+      }
+
+      var p = JSON.parse(b);
+
+      if (id_token.sub != p.sub) {
+        return cb(new Error('sub does not match, this should not happen'));
+      }
+      // We check if the current session was authenticated with 2FA (id_token knows this)
+      var two_factor = false;
+      if (id_token['fxa-aal'] >= 2) {
+        two_factor = true;
+      } else {
+        // if not , it might be the user just enabled 2FA and has not logged back in
+        // for now, handle this like GitHub 2FA by looking it up in the user info endpoint
+        // note that if for caching reasons this is not set, we may still get the incorrect value
+        // and in that case there's nothing we can currently do / user has to wait or log back in to get it "faster"
+        two_factor = p.twoFactorAuthentication;
+      }
+
+      return cb(null, {
+        user_id: id_token.sub,
+        picture: p.avatar,
+        preferredLanguage: p.locale,
+        email: p.email,
+        email_verified: true,
+        fxa_sub: id_token.sub,
+        amr: id_token.amr,
+        acr: id_token.acr,
+        fxa_twoFactorAuthentication: two_factor
+      });
+    }
+  );
+}