Identity/AttachedServices/DeploymentPlanning/FirefoxAccountsBridge

Overview

This is a working proposal for the backend architecture and deployment of the Firefox Accounts Bridge.

This service provides a web-based UI to the API operations of the Firefox Accounts Service, essentially making it look like a standard BrowserID Identity Provider. In its current incarnation, it is an entirely static site that delivers JavaScript and HTML to the client browser.

Goals and Milestones

The goal for Q32013 is to have this service Production Ready.

This does not mean having a fully-deployed production environment! With the implementation of the storage component still outstanding, there's no point in standing up an authentication service all by itself. It does mean that we need the ability to do automated deployments that pass loadtests, meet operational and security criteria, and generally inspire confidence that we could roll things out to production without major hiccups.

These are the individual milestones on our way to said goal, broken down into weekly chunks:

• Aug 09:
  • usable manual-deploy dev environment tooling
    • plain old awsbox
• Aug 16:
  • defined testable "success criteria" for FxA Bridge:
    • Target number of concurrent users.
    • Target number of login operations per second.
• Aug 23:
  • (reserved for work on Firefox Accounts)
• Aug 30:
  • loadtesting code written and debugged.
    • this will use loads and simply request the necessary assets from the server.
    • there's no heavy-lifting and no server-side API here, so the loadtests will be very thin.
• Sep 6:
  • automated single-region loadtest deployment
    • built using cloudformation and awsboxen
    • including shipping logs and performance data to a Heka/ES/Kibana box for analysis
  • loadtests run against FxA Bridge loadtest environment.
    • Dependencies: stable and performant loads cluster infrastructure, usable log analysis tools
• Sep 13:
  • fixed any load-related issues
  • (mostly reserved for work on Firefox Accounts)
• Sep 20:
  • tweaking, tweaking, always tweaking...
• Sep 27:
  • security review signoff.
  • svcops signoff.
• Sep 30:
  • Production Ready!

There are likely a lot of SvcOps details missing from this plan, e.g. monitoring and infrasec things. We'll do what we can to get those in place, but I'm OK with an initial loadtest environment that's taking some of that stuff.

Dev Deployment

Development deployments are done using a plain old awsbox. The service has no special requirements since it's just serving static assets.

Loadtest Deployment

We will script this in the firefox-account-bridge repo, using awsboxen/cloudformation. That should suffice for initial QA and loadtesting purposes. If and when we need to migrate to other SvcOps tools, the cloudformation stuff will be a good starting point.

Architecture

This will be a multi-region high-availability deployment. Since this is intended to provide the login UI for desktop devices, it should have a least the same availability as the Firefox Accounts service itself.

This is a very skinny and simple service, serving only statics assets. We could probably run it through a CDN. To begin we'll run an autoscale cluster of machines behind a simple public ELB:

    client       +------------+    +--------------------+
    requests --> | Public ELB |--->| FxA Bridge Cluster |
                 +------------+    +--------------------+

Security

This service sends JavaScript into which the user will enter their FxA password, so we need good security checks in place to make sure this isn't man-in-the-middle'd or otherwise compromised. Similar level of security to the current persona.org web-based UI.

So, what do we do to keep this secure?

TDB.

Supporting Infrastructure

Each machine will run a local Heka agent to aggregate logs. They will be shipped to a stand-alone Heka router assocated with the region, which will in turn forward them to the shared ElasticSearch /Kibana thingy.