956222 - Let tokenserver use a remote verifier service

Status: VERIFIED FIXED

(Cloud Services Graveyard :: Server: Token, defect)

Description

[Ryan Kelly [:rfkelly]]

The tokenserver currently does local verification of BrowserID assertions.  There's some impending churn in the protocol and formats which will mean this stops working sometime soon.

To reduce risk and dependencies for the sync+fxa sprint, I think we should reconfigure things so that it can use the remote verifier service.  This means we would support the updated formats as soon as they're live, and can work on local verification off the critical path.

Were there operational reasons for avoiding remote verification in the initial implementation, or was it purely for efficiency?

FWIW I have a minimal implementation of this already in a github branch:

    https://github.com/mozilla-services/tokenserver/commit/b0098553475863aa1e904f8767b130db735ff4bd

But maybe there's something better/neater we can do for production.

Comment 1

[Alexis Metaireau (:alexis)]

The intention was to reduce the cost of the roundtrip to the network.

By doing the verification remotely, we (potentially) transform the task from a cpu-bound to network-bound one. Depending the amount of traffic we expect, that may or may not be an acceptable solution.

If the BrowserID protocol changes anytime soon, maybe we should make PyBrowserID compatible with these changes rather than depending on the remote verifier?

Comment 2

[Tarek Ziadé (:tarek)]

Another option is to deploy the native browser id verifier (e.g. the node? one) on the token server itself, and have the token server use it. That would make our life easier to deploy something more tolerant to network partitions.

Comment 3

[Ryan Kelly [:rfkelly]]

> If the BrowserID protocol changes anytime soon, maybe we should make PyBrowserID compatible
> with these changes rather than depending on the remote verifier?

This should definitely be the long-term plan, but given that the protocol changes are still landing on the nodejs side, I see a real risk in trying to get this done as part of the FF29 deadline.

Comment 4

[Ryan Kelly [:rfkelly]]

I've landed a simple implementation of this in https://github.com/mozilla-services/tokenserver/pull/19.  This should suffice for the initial deployment deadline, and we can iterate on the performance aspects while fxa+sync rides the trains.

Comment 5

[James Bonacci [:jbonacci]]

Verified here: https://github.com/mozilla-services/tokenserver

Comment 6

[James Bonacci [:jbonacci]]

REFs:

https://github.com/mozilla-services/puppet-config/pull/59