Support service accounts in the chromoting host.

Support service accounts in the chromoting host.

This change allows running a host *already configured* with service account credentials. Support for obtaining service account credentails during host setup will come in follow up CLs.

BUG=224742
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=217941

[rmsousa, 2013-07-23 21:50:21]

https://codereview.chromium.org/19796006/diff/1/remoting/host/signaling_conne...
File remoting/host/signaling_connector.cc (right):

https://codereview.chromium.org/19796006/diff/1/remoting/host/signaling_conne...
remoting/host/signaling_connector.cc:234: // Service accounts use different API
keys, as they use the client app flow.
Yuck. Longer explanation - Service Accounts use the client app flow
(redirect_uri = oob). Our current host client IDs only support the server flow
(redirect_uri = real server, in our case talk gadget). The dev console doesn't
allow the same client IDs to be used for both flows. So we need to add another
client ID, to be used specifically for service accounts.

On the upside, this means that once we fully move to appsv2 and service
accounts, we can get rid of the old oauth.js flow and client IDs entirely - the
client will use the new identity API flow, and the host will use the service
account flow.

https://codereview.chromium.org/19796006/diff/1/remoting/protocol/me2me_host_...
File remoting/protocol/me2me_host_authenticator_factory.cc (right):

https://codereview.chromium.org/19796006/diff/1/remoting/protocol/me2me_host_...
remoting/protocol/me2me_host_authenticator_factory.cc:114: // TODO(rmsousa):
Check that local JID is host owner or robot.
I'm not even sure we want to do this. I think at the end of the day, as long as
both policy checks and connection checks are performed against the host owner
(i.e. enterprises can control *who can connect* to the host), the JID with which
the host is connected is pretty much irrelevant. It's just a communication
channel.

[Sergey Ulanov, 2013-07-23 23:37:32]

lgtm

https://codereview.chromium.org/19796006/diff/1/google_apis/google_api_keys.h
File google_apis/google_api_keys.h (right):

https://codereview.chromium.org/19796006/diff/1/google_apis/google_api_keys.h...
google_apis/google_api_keys.h:74: CLIENT_REMOTING_SERVICE_ACCOUNT,
Maybe call it REMOTING_HOST? Long term it will be the only client ID used by the
host.

https://codereview.chromium.org/19796006/diff/1/remoting/protocol/me2me_host_...
File remoting/protocol/me2me_host_authenticator_factory.cc (right):

https://codereview.chromium.org/19796006/diff/1/remoting/protocol/me2me_host_...
remoting/protocol/me2me_host_authenticator_factory.cc:114: // TODO(rmsousa):
Check that local JID is host owner or robot.
On 2013/07/23 21:50:21, rmsousa wrote:
> I'm not even sure we want to do this. I think at the end of the day, as long
as
> both policy checks and connection checks are performed against the host owner
> (i.e. enterprises can control *who can connect* to the host),

That's relevant not only in the enterprise case. All users would want to control
who has access to the host.

> the JID with which
> the host is connected is pretty much irrelevant. It's just a communication
> channel.

I agree - there is no reason host will need to validate local_jid here.

https://codereview.chromium.org/19796006/diff/1/remoting/protocol/me2me_host_...
remoting/protocol/me2me_host_authenticator_factory.cc:116: if (slash_pos ==
std::string::npos) {
I think you can remove this code now, because slash_pos is no longer used.

[rmsousa, 2013-07-26 22:31:41]

(+joi for the added API key)

[Jói, 2013-08-12 10:16:18]

LGTM

[commit-bot: I haz the power, 2013-08-14 01:07:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/7001

[commit-bot: I haz the power, 2013-08-14 01:53:05]

Retried try job too often on chromium_presubmit for step(s) presubmit
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=chromium_p...

[commit-bot: I haz the power, 2013-08-14 02:19:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/7001

[commit-bot: I haz the power, 2013-08-14 03:17:08]

Retried try job too often on linux_rel for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2013-08-15 00:02:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/43001

[commit-bot: I haz the power, 2013-08-15 01:08:57]

Retried try job too often on linux_aura for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_aura...

[commit-bot: I haz the power, 2013-08-15 01:13:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/43001

[commit-bot: I haz the power, 2013-08-15 02:23:37]

Retried try job too often on mac_rel for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2013-08-15 19:59:34]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/89001

[commit-bot: I haz the power, 2013-08-15 20:44:33]

Retried try job too often on mac_rel for step(s) unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2013-08-16 01:02:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rmsousa@chromium.org/19796006/89001

[commit-bot: I haz the power, 2013-08-16 05:18:43]

Change committed as 217941