Reusing names of policy keys from policy_constants.h

components/policy/resources/policy_templates.json

Index: components/policy/resources/policy_templates.json
diff --git a/components/policy/resources/policy_templates.json b/components/policy/resources/policy_templates.json
index 7f159c7c76b6f9208b47f88e76661cbb0e787d9a..399d1037f8e07099094d27f953633c24094f1c3a 100644
--- a/components/policy/resources/policy_templates.json
+++ b/components/policy/resources/policy_templates.json
@@ -123,7 +123,7 @@
 #   persistent IDs for all fields (but not for groups!) are needed. These are
 #   specified by the 'id' keys of each policy. NEVER CHANGE EXISTING IDs,
 #   because doing so would break the deployed wire format!
-#   For your editing convenience: highest ID currently used: 284
+#   For your editing convenience: highest ID currently used: 289
 #
 # Placeholders:
 #   The following placeholder strings are automatically substituted:
@@ -745,6 +745,96 @@
 
           If this policy is left not set, or if it is set to an empty string, the remote access host will be allowed to use any available port, unless the policy <ph name="REMOTEACCESSHOSTFIREWALLTRAVERSAL_POLICY_NAME">RemoteAccessHostFirewallTraversal</ph> is disabled, in which case the remote access host will use UDP ports in the 12400-12409 range.''',
         },
+        {
+          'name': 'RemoteAccessHostMatchUsername',
+          'type': 'main',
+          'schema': { 'type': 'boolean' },
+          'supported_on': ['chrome.*:25-'],

[bartfab (slow), 2015/01/09 19:20:15]

So these policies were actually working as of Chrome 25, Chrome 28, etc., but
were not listed in policy_templates.json? If so, thanks for fixing that. All
policies should be listed in this file.

[Łukasz Anforowicz, 2015/01/09 19:47:27]

Yes, but this assumes that when you say "Chrome 25" then it also covers
Chromoting host (separate [daemon/service] process, same project).  I've been
discussing with mnissler@ if we should consider moving Chromoting-specific
policies to a separate policy_templates.json (generating separate,
Chromoting-specific chromoting_policy_constants.h/.cc etc.).  It's not yet clear
what more has to be involved in such move (i.e. to make sure that Chrome tools
for enterprise admins continue to cover Chromoting policies).  But, given that
all the other Chromoting policies are listed here, I think listing the 5 missing
ones is the right thing to do (at the very least this enables getting rid of
code under src/remoting/host/policy_hack and reusing src/components/policy -
this is under review at crrev.com/830193002 but depends on the current
changelist being checked-in first).

[bartfab (slow), 2015/01/12 13:16:33]

The CL description provides no context, so I had no idea where these policies
came from and what they were for. With your additional explanations, I
understand what they are for now. I agree that using "chrome" when you mean
"chromoting host" is strange. How about this middle ground: Do not introduce
separate json files and processing mechanisms but add new supported_on constants
like "chromoting.linux," "chromoting.win," etc. You could then tweak grit to
output constants for these policies (making it easy to use them in code) but
leave them out from e.g. the ADM templates we generate.

[Łukasz Anforowicz, 2015/01/12 18:32:58]

Good point.  I've added this to the CL description.
I am not sure what you mean by "ADM templates", but continuing to support
Chromoting policies by tools for enterprise admins is an explicit requirement
here (and one of the reasons to keep using the policy_templates.json from under
components/policy).

At any rate, I agree with the desire to move Chromoting policies to a separate
location (either a separate chromoting_policy_templates.json or a separate
supported_on flags), but I think this should be done in a separate changelist:

- The current changelist just preserves the status quo (i.e. existance of 10
chromoting-specific policies under policy_templates.json).

- The current changelist is needed to remove platform-specific code under
src/remoting/host/policy_hack that duplicates the functionality of
src/components/policy (in fact it got copy&pasted from there long time ago
before this was a sharable component).

- Separationg Chromoting policies is quite involved in itself and therefore
belongs in a separate changelist: need to account for it2me/chromeos
differences, need to make sure that tools for enterprise admins continue to
support chromoting policies, need to discuss and identify mechanics of the move
(i.e supported_on VS separate chromoting_policy_templates.json VS just filter
the Schema in code).

+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': False,
+          'id': 285,
+          'caption': '''Requires that the name of the local user and the remote access host owner match''',
+          'desc': '''Requires that the name of the local user and the remote access host owner match.
+
+          If this setting is enabled, then the remote access host compares the name of the local user (that the host is associated with) and the name of the Google account registered as the host owner (i.e. "lukasza" if the host is owned by "lukasza@chromium.org" Google account).  The remote access host will not start if the name of the host owner is different from the name of the local user that the host is associated with.  RemoteAccessHostMatchUsername policy should be used together with RemoteAccessHostDomain to also enforce that the Google account of the host owner is associated with a specific domain (i.e. "chromium.org").

[Sergey Ulanov, 2015/01/09 00:46:56]

nit: Maybe use something like johndoe@example.com instead of your account in the
example

[Łukasz Anforowicz, 2015/01/09 19:47:27]

Done.

+
+          If this setting is disabled or not set, then the remote access host can be associated with any local user.
+
+          This policy is ignored on Windows.''',

[bartfab (slow), 2015/01/09 19:20:15]

Please set 'supported_on' to the actual supported platforms instead of
documenting this here.

[Łukasz Anforowicz, 2015/01/09 19:47:27]

Thanks for pointing this out.  Done.

+        },
+        {
+          'name': 'RemoteAccessHostTokenUrl',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:28-'],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'https://example.com/issue',
+          'id': 286,
+          'caption': '''URL where remote access clients should obtain their authentication token''',
+          'desc': '''URL where remote access clients should obtain their authentication token.
+
+          If this policy is set, the remote access host will require authenticating clients to obtain an authentication token from this URL in order to connect. Must be used in conjunction with RemoteAccessHostTokenValidationUrl.
+
+          This feature is currently disabled server-side.''',
+        },
+        {
+          'name': 'RemoteAccessHostTokenValidationUrl',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:28-'],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'https://example.com/validate',
+          'id': 287,
+          'caption': '''URL for validating remote access client authentication token''',
+          'desc': '''URL for validating remote access client authentication token.
+
+          If this policy is set, the remote access host will use this URL to validate authentication tokens from remote access clients, in order to accept connections. Must be used in conjunction with RemoteAccessHostTokenUrl.
+
+          This feature is currently disabled server-side.''',
+        },
+        {
+          'name': 'RemoteAccessHostTokenValidationCertificateIssuer',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:28-'],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': 'Example Certificate Authority',
+          'id': 288,
+          'caption': '''Client certificate for connecting to RemoteAccessHostTokenValidationUrl''',
+          'desc': '''Client certificate for connecting to RemoteAccessHostTokenValidationUrl.
+
+          If this policy is set, the host will use a client certificate with the given issuer CN to authenticate to RemoteAccessHostTokenValidationUrl. Set it to "*" to use any available client certificate.
+
+          This feature is currently disabled server-side.''',
+        },
+        {
+          'name': 'RemoteAccessHostDebugOverridePolicies',
+          'type': 'string',
+          'schema': { 'type': 'string' },
+          'supported_on': ['chrome.*:25-'],
+          'features': {
+            'dynamic_refresh': True,
+            'per_profile': False,
+          },
+          'example_value': '{ "RemoteAccessHostMatchUsername": true }',
+          'id': 289,
+          'caption': '''Policy overrides for Debug builds of the remote access host''',
+          'desc': '''Overrides policies on Debug builds of the remote access host.
+
+          The value is parsed as a JSON dictionary of policy name to policy value mappings.''',

[bartfab (slow), 2015/01/09 19:20:15]

I presume the "policy" here has nothing to do with Chrome policy? Could you
clarify this for posterity's sake?

[Łukasz Anforowicz, 2015/01/09 19:47:27]

I tried to point this out by mentioning "remote access host" above (this is what
it's been called in all the other chromoting-related elements in this file).

Could you please suggest a wording that you think would work better?

BTW: let me bring your attention to a code review comment here, where we are
discussing desire to potentially yank out this policy in the future:
https://codereview.chromium.org/830193002/diff/20001/remoting/host/policy_hac...
(next to: FILE_PATH_LITERAL("/etc/opt/chrome/policies"))

[bartfab (slow), 2015/01/12 13:16:33]

I think the key problem is that these policies are intermixed with the 250+
Chrome policies. It is totally unexpected for the reader that four out of 250
policies apply to the chromoting host, not Chrome itself. It is OK (and arguably
good) to put them in this file. But it should be really clear that these
policies are different. They should be differentiated by supported_on constants,
probably even clearer wording, possibly an additional flag like 'product':
'chromoting_host' and maybe by moving them to a dedicated section of the file,
e.g. the very end, after Chrome OS device policies.

[Łukasz Anforowicz, 2015/01/12 18:32:59]

10 Chromoting policies have been present in policy_templates.json forever (well,
since 2011 :-).  I am just adding 5 policies that are missing (and that prevent
removal of the platform-specific code under src/remoting/host/policy_hack that
got copy&pasted from src/components/policy before it became a shareable
component).

$ grep name.*:.*RemoteAccess components/policy/resources/policy_templates.json 
      'name': 'RemoteAccess',
          'name': 'RemoteAccessClientFirewallTraversal',
          'name': 'RemoteAccessHostFirewallTraversal',
          'name': 'RemoteAccessHostDomain',
          'name': 'RemoteAccessHostRequireTwoFactor',
          'name': 'RemoteAccessHostTalkGadgetPrefix',
          'name': 'RemoteAccessHostRequireCurtain',
          'name': 'RemoteAccessHostAllowClientPairing',
          'name': 'RemoteAccessHostAllowGnubbyAuth',
          'name': 'RemoteAccessHostAllowRelayedConnection',
          'name': 'RemoteAccessHostUdpPortRange',
          'name': 'RemoteAccessHostMatchUsername',
          'name': 'RemoteAccessHostTokenUrl',
          'name': 'RemoteAccessHostTokenValidationUrl',
          'name': 'RemoteAccessHostTokenValidationCertificateIssuer',
          'name': 'RemoteAccessHostDebugOverridePolicies',

$ git blame components/policy/resources/policy_templates.json | grep
name.*:.*RemoteAccess
lists the following (really old) commits:

268954f65c (garykac@chromium.org      2011-07-26 18:56:10 +0000  585)
48428b844d (garykac@chromium.org      2012-08-06 21:49:42 +0000  605)
60e2ac0880 (jamiewalch@chromium.org   2012-08-13 21:17:54 +0000  663)
562378fd4f (jamiewalch@chromium.org   2013-08-02 20:13:55 +0000  681)
3a5b82c105 (psj@chromium.org          2014-02-20 13:28:14 +0000  697)
11f9efbe87 (noamsml@google.com        2014-04-30 17:04:23 +0000  713)

[bartfab (slow), 2015/01/13 18:49:45]

An interesting thing you said above is that you are just preserving the status
quo. But as long as these five policies were not listed in
policy_templates.json, they did not show up in any of our admin templates. So by
adding them here, you are changing the status quo. After your CL lands, the
admin templates used to manage Chrome will show five new policies, none of which
actually affect Chrome.

You pointed out that there are 10 Chromoting host policies in
policy_templates.json already. Given that precedent, I think it is OK to move
the remaining 5 policies in here too for consistency. It would be great to
figure out where these policies should live in the longer term and move them
there eventually (in a follow-up CL) though.

[Łukasz Anforowicz, 2015/01/13 20:10:24]

Yes.  This is a bit painful, but probably the right thing to do.  I've added you
to an email conversation where I am trying to figure out the pieces needed to
make this happen.

+        },
       ],
     },
     {