for desktop

current http://cl.ly/1q1f1E1Y1z1B3W011l3k
desired http://cl.ly/2Z1T461P0d0D0c2A1201

We have 0 code coverage from unit tests.

Make sure we're not accidentally storing any user data from the providers.

@benadida suggested removing our /proxy/:email perf optimization.

1. It breaks the BrowserID protocol

2. If it takes the proxied IdP a while to respond, the user gets not visual feedback

So we should build in an in-determine progress indicator and do the step of starting the Proxied Strategy from this page.
Auth/Provisioning URLs wouldn't have :email.

I didn't know that jwcrypto ships with bin/generate-keypair.

We should remove our script, update the docs, and rename the default configs from server_public_key.json to key.publickey.

Note: generate-keypair and gen_keys.js are compatible.

/CC @callahad as a heads up.

Steps to Reproduce

1. Log into sample RP with browserid with [email protected] (or whatever valid gmail address)
2. Complete flow
3. In a new tab log out of your google account
4. Log into sample RP with browserid and click 'this is not me'.
5. Use [email protected]

Actual:
6) Click Verify link
7) On Google OpenID screen accept login

Note: Your being asked to log in as [email protected], not [email protected]

8. Note: bigtent login completion page keeps refreshing

Expected:
Not quite sure, probably: Detect email mismatch and show error message. Do Not go through OpenID flow.

Alternatives: In provision maybe we can detect the [email protected] vs [email protected] and show the user a screen asking them to log out of gmail?

The loadbalancer needs to see /__heartbeat__ returning 200 OK with a body of ok before it will let the traffic flow.

If we can't silently auth the user, that means we're sending them to a login / auth page for their IdP... we should probably explicitly remind them to log out of their IdP when they're done with their session :)

The holistic approach is - resize the popup to the right size for the proxy email provider. Once they hand back to us, restore back to our preferred size.

Yahoo resizes to a small window. When they hand back to us, our layout detects the small width and uses the mobile layout. It's weird.

Currently the BigTent service maintains a session. The only thing stored in that session is the email address of your last successful authentication.

We should probably store up to N addresses and to KISS for 1.0, we'll store a list of email addresses. This will keep growing as the user logs in with different addresses.

This list will disappear once a session is destroyed or times out.

Steps to Reproduce

1. Log into sample RP with browserid with [email protected] (or whatever valid gmail address)
2. Complete flow
3. Log into sample RP with browserid and click 'this is not me'.
4. Use [email protected]
5. Complete flow
6. Log into sample RP with browserid and click 'this is not me'.
7. Use [email protected] again (from step 1) click 'Next'

Actual:
You're prompted with OpenID flow

Expected:
You should be provisioned for [email protected] without hitting the OpenID flow.

If we can, we want to hint to Google what the email address is that the user is attempting to request.

A user may deny the OpenID or OAuth request. We should handle this cancellation by returning them to the BID sign in screen.

Services is building Metlog which provides statsd and logging support.

https://github.com/mozilla-services/metlog-node/

When a user clicks "No thanks" or "No" on the Google or Hotmail popups, we just start the flow over and immediately send them right back to that same prompt.

Infinite loop style.

If the user cancels, we should pop them back up to the root Persona account-chooser dialog.

Review how BigTent handles sessions.

Steps to Reproduce

1. Using the BigTent flow, log in to an RP as [email protected].
2. Log out of the RP, Gmail, and BrowserID.
3. Try to log back into the RP as [email protected]

Expected Results

Prompted to log into Google

Actual Results

"Address verified!"

Discussion.

This seems Really Bad. Since there's no way for a user to log out of BigTent, traditional safety advice ("always log out of the websites you were using") does not protect users.

Steps to Repro

1. On port 10001 use 'Require a specific email' field
2. Click get an assertion

Actual
'verify email' button

Expected:
Proxy IdP flow

.

Figure out the right time to lower case email addresses that have been authenticated, and the right time to compare them to BID claimed email.

Before we store an email address in the session, they should be verified and scrubbed.

We output them in /provision.js which could be a XSS concern.

Pop this out of the flow.

http://cl.ly/0y15272W1b0A2P1Z0F2S

@lloyd mentioned that a useful property of BrowserID's loadgen, is that you can manually test the system while under load.

This is useful for seeing how responsive the app is.

Currently, this isn't possible with our load plan. The mock open id provider can only handle static inputs.

In a 'bigtent' branch of mozilla/browserid, we should add a path of logic that is neither a primary nor a secondary, but which delegates to bigtent based on a whitelist of email addresses.

Probably the logic looks like:

1. Is this email address for a primary? If yes do primary flows
2. Is this email address supported by bigtent? If yes do proxy flows
3. else do Secondary flows

From an interface perspective, bigtent will probably look like a primary for provisioning and authentication.

http://skitch.com/oztenskitch/8wr18/bug-gmail-responsive

When we break out crypto into a different process, it shouldn't have the same name as keysigner.

This is because it's statsd prefix should be browserid.bigtent_keysigner or something.

Our statsd library will do browserid.<PROCESS NAME> for the prefix.

Yahoo and Google are supported via passport libraries.

Research best strategy for hotmail login (OAuth, windows live, ...?) and add support so that hotmail users can auth via BigTent.

Coming out of load testing work, a performance improvement to BigTent would be to store OpenID associations in a shared memory so that this cache scales horizontally.

We could put these into a memcached server with a 5 minute timeout.

If memcache is down, there is no problem as this cache saves a HTTP request between BigTent and the IdP, but can still perform this extra step.

@fetep what is the prefered solution: memcache, redis or other?

If a user isn't logged in to yahoo, the yahoo login screen will resize the window to it's shape. After this step, our dialog will remain in that new size.

See #23 for additional documentation.

Our production infrastructure keeps everything behind an HTTP proxy. We need to route all external requests through this proxy.

As far as I can tell, doing so will require patching node-openid and node-oauth.

When create a certificate for a user, we should chain it to a certificate which has been signed by the BrowserID private key.

This chained cert should expire in 1 year. We should have an alter 1 month before it expires. We should document the operational requirements around this chainedCert.

We need to document all outbound requests and URLs so ops can:

1. Limit allowed traffic off the box
2. Cache web service requests
3. Detect and react to slow/broken services

3 will/may be provided by our higher level statsd work.

There is a codepath that tries to load a private key, even though BT doesn't need private keys now.

This issue will capture interesting monitoring points which we should instrument with statsd.

• auth flow started (overall as well as per email service provider)
• auth flow errored out or was canceled
• auth flow completed, session created
• auth via session (cache hit)
• server restart

Chatting with @jrgm and @fetep - We need a way to load test BigTent

"we don't want to load test gmail, yahoo, or hotmail's servers"

"We might have to mock it, and introduce some simulated delays and stuff"

We need to do this.

Clean up ozten's crappy code. Match mozilla/browserid's style.

Our mock openid server has a hardcoded response, instead of generating a valid response.
This means we have a valid load test up until PassportJS checks the signature of the server's response. Then it bails. Bailing means we never auth the user, so we have to fake the rest of the flow.

I've created a node module which could be used to fix this openid response signature:
https://github.com/mozilla/browserid-bigtent/blob/loady/server/tests/lib/mock_proxy_ip/assoc_session.js#L62

I've read the OpenID spec for DH-SHA256, but not knowing math or crypto am stumped.

Can you patch associate_session such that it can be used from mock_proxy_idp and generate signatures that will pass PassportJS' checks?

Hopefully you can do this in isolation and I'll do the integration work, but I can also add more detail if you want on how to setup the load test to see this in action.

We should add aws box to this project, so we can deploy quick and easy like...

We should be flexible in how browserid is configured and how BigTent is deployed.

We should change the whitelist from

['gmail.com', 'yahoo.com', 'hotmail.com']

to

{
  "gmail.com": "https://google.login.persona.org",
  "yahoo.com": "https://yahoo.login.persona.org",
  "hotmail.com": "https://microsoft.login.persona.org"
}

In the short term or during development, these can all be set to the same host.

Having per IdP allows us to limit the scope of a private key to each domain. It allows us to scale each individually.

For parity with the certifier, we should probably make the public key location configurable.

Much like mozilla/browserid, bigtent should have a 10k limit on incoming POST bodies.

Reported by @callahad, If a user signs out of Google and/or the BrowserID dialog, BigTent still has an active session. The next time they go to use the last email address which they had just used, provisioning will authenticate them without checking with the proxied IdP.

Steps to Repro:

1. Log in with [email protected]
2. In a seperate tab, log out of gmail.com
3. On example RP, log in
4. Click 'this is not me'
5. Enter [email protected] and click 'Next'

Expected
BigTent should start the OpenID or OAuth flow for the IdP.

Actual
BigTent sees an active session and vouches for user.

See https://github.com/mozilla/browserid-bigtent/blob/af3dd982a2c68e50ea424c40feeb2af1ac07d64a/server/routes.js#L275

This should be localized.

Hotmail addresses are prompted for passwords instead of using BigTent. Why?

When attempting to log in with my gmail account in a fresh Firefox session (with Private Browsing), req.session doesn't seem to get populated with my claimed email. This results in the following backtrace when checking for a match:

TypeError: Cannot call method 'toLowerCase' of null
    at /Users/dan/Projects/Mozilla/browserid-bigtent/server/lib/passport_google.js:94:70
    at Array.forEach (native)
    at /Users/dan/Projects/Mozilla/browserid-bigtent/server/lib/passport_google.js:86:25
    at callbacks (/Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/express/lib/router/index.js:272:11)
    at /Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/passport/lib/passport/middleware/authenticate.js:97:9
    at /Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/passport/lib/passport/http/request.js:46:7
    at pass (/Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/passport/lib/passport/index.js:205:30)
    at /Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/passport/lib/passport/index.js:213:36
    at /Users/dan/Projects/Mozilla/browserid-bigtent/server/lib/passport_google.js:26:3
    at pass (/Users/dan/Projects/Mozilla/browserid-bigtent/node_modules/passport/lib/passport/index.js:213:7)

Line in question: https://github.com/mozilla/browserid-bigtent/blob/master/server/lib/passport_google.js#L94

Screenshot of node inspector highlighting the error: http://d.pr/i/7PEo

via email from @benadida

Split bin/bigtent code into two components: one that does almost everything except keysigning, and the other that does keysigning. As in the typical BrowserID code, the keysigning functionality should be proxied from the first component to the other. This is so we have a layer of defense in case attackers penetrate the top-level machine, they don't have access to the keysigning functionality.

I recommend we do this in much the same way we BrowserID splitting. In fact, Lloyd's figured out so much of the details of proxying properly that we really should reuse his code as is, maybe even turn it into a reusable.

Currently one has to manually install and run a certifier.

This should happen automagically with gith push master:master

For consideration, when you the user enters the email as [email protected], we could strip out the +tag, auth as [email protected], but use the myname+tag address as the name in browserid.

This would mostly be something to ease testing of multiple accounts, and it may complicate things too much for this release; I can easily go create some gmail/yahoo/hotmail accounts for this testing round.

However, at minimum, we do need a bit better handling of such an email address, since right now, I get an error when using an address like that.

Plugin and add to error or other screen.

Much like https://browserid.org/ver.txt
and
https://browserid.org/_heartbeat_

There are certain features we need for troubleshooting and monitoring. They should be the same across servers (Vinz Clortho, BrowserID, etc)