Public Sessions: fetch device robot api token during enterprise enrollment.

chrome/browser/chromeos/policy/enrollment_handler_chromeos.h

Index: chrome/browser/chromeos/policy/enrollment_handler_chromeos.h
diff --git a/chrome/browser/chromeos/policy/enrollment_handler_chromeos.h b/chrome/browser/chromeos/policy/enrollment_handler_chromeos.h
index c6f79441752345c8d8a467eb760a0c02e82ba6f9..310f01c6c368c91820b8b6843fbac30ae7d90571 100644
--- a/chrome/browser/chromeos/policy/enrollment_handler_chromeos.h
+++ b/chrome/browser/chromeos/policy/enrollment_handler_chromeos.h
@@ -15,6 +15,7 @@
 #include "chrome/browser/chromeos/policy/device_cloud_policy_validator.h"
 #include "chrome/browser/policy/cloud/cloud_policy_client.h"
 #include "chrome/browser/policy/cloud/cloud_policy_store.h"
+#include "google_apis/gaia/gaia_oauth_client.h"
 
 namespace enterprise_management {
 class PolicyFetchResponse;
@@ -28,12 +29,16 @@ class EnterpriseInstallAttributes;
 // devices. The process is as follows:
 //   1. Given an auth token, register with the policy service.
 //   2. Download the initial policy blob from the service.
-//   3. Verify the policy blob. Everything up to this point doesn't touch device
+//   3. Download the OAuth2 authorization code for device-level API access.
+//   4. Download the OAuth2 refresh token for device-level API access and store
+//      it.
+//   5. Verify the policy blob. Everything up to this point doesn't touch device

[Mattias Nissler (ping if slow), 2013/03/19 06:33:08]

I think we should first verify the policy blob and then do the OAuth handshake.

[David Roche, 2013/04/02 01:59:25]

Right now the validate step also saves the policy and locks the device.  So, the
reason I put the oauth handshake first was so that it could be treated as a
required part of registration before the device is locked.

If I'm to move it after validation, I'd have to break out the locking into
another step that goes after the handshake.

Do you think it's important that this be after verification, or do you dislike
that it's between the policy fetch and verification steps?  An alternative would
be move this before the policy fetch.

[Mattias Nissler (ping if slow), 2013/04/02 14:16:46]

Validation and locking already have their separate steps? Maybe I'm missing
something?
The rationale here is that there might be a policy in the future for configuring
whether we actually want the device-level robot (it surely does have security
implications). If you need the device policy, the first step you can use it is
after policy verification.

 //      state.
-//   4. Establish the device lock in installation-time attributes.
-//   5. Store the policy blob.
+//   6. Establish the device lock in installation-time attributes.
+//   7. Store the policy blob.
 class EnrollmentHandlerChromeOS : public CloudPolicyClient::Observer,
-                                  public CloudPolicyStore::Observer {
+                                  public CloudPolicyStore::Observer,
+                                  public gaia::GaiaOAuthClient::Delegate {
  public:
   typedef DeviceCloudPolicyManagerChromeOS::AllowedDeviceModes
       AllowedDeviceModes;
@@ -65,24 +70,36 @@ class EnrollmentHandlerChromeOS : public CloudPolicyClient::Observer,
   // CloudPolicyClient::Observer:
   virtual void OnPolicyFetched(CloudPolicyClient* client) OVERRIDE;
   virtual void OnRegistrationStateChanged(CloudPolicyClient* client) OVERRIDE;
+  virtual void OnRobotAuthCodesFetched(CloudPolicyClient* client) OVERRIDE;
   virtual void OnClientError(CloudPolicyClient* client) OVERRIDE;
 
   // CloudPolicyStore::Observer:
   virtual void OnStoreLoaded(CloudPolicyStore* store) OVERRIDE;
   virtual void OnStoreError(CloudPolicyStore* store) OVERRIDE;
 
+  // GaiaOAuthClient::Delegate:
+  virtual void OnGetTokensResponse(const std::string& refresh_token,
+                                   const std::string& access_token,
+                                   int expires_in_seconds) OVERRIDE;
+  virtual void OnRefreshTokenResponse(const std::string& access_token,
+                                      int expires_in_seconds) OVERRIDE;
+  virtual void OnOAuthError() OVERRIDE;
+  virtual void OnNetworkError(int response_code) OVERRIDE;
+
  private:
   // Indicates what step of the process is currently pending. These steps need
   // to be listed in the order they are traversed in.
   enum EnrollmentStep {
-    STEP_PENDING,        // Not started yet.
-    STEP_LOADING_STORE,  // Waiting for |store_| to initialize.
-    STEP_REGISTRATION,   // Currently registering the client.
-    STEP_POLICY_FETCH,   // Fetching policy.
-    STEP_VALIDATION,     // Policy validation.
-    STEP_LOCK_DEVICE,    // Writing installation-time attributes.
-    STEP_STORE_POLICY,   // Storing policy.
-    STEP_FINISHED,       // Enrollment process finished, no further action.
+    STEP_PENDING,             // Not started yet.
+    STEP_LOADING_STORE,       // Waiting for |store_| to initialize.
+    STEP_REGISTRATION,        // Currently registering the client.
+    STEP_ROBOT_AUTH_FETCH,    // Fetching device API auth codes.
+    STEP_ROBOT_AUTH_REFRESH,  // Fetching/storing device API refresh tokens.
+    STEP_POLICY_FETCH,        // Fetching policy.
+    STEP_VALIDATION,          // Policy validation.
+    STEP_LOCK_DEVICE,         // Writing installation-time attributes.
+    STEP_STORE_POLICY,        // Storing policy.
+    STEP_FINISHED,            // Enrollment process finished, no further action.
   };
 
   // Starts registration if the store is initialized.
@@ -107,6 +124,7 @@ class EnrollmentHandlerChromeOS : public CloudPolicyClient::Observer,
   DeviceCloudPolicyStoreChromeOS* store_;
   EnterpriseInstallAttributes* install_attributes_;
   scoped_ptr<CloudPolicyClient> client_;
+  scoped_ptr<gaia::GaiaOAuthClient> gaia_oauth_client_;
 
   std::string auth_token_;
   std::string client_id_;