Share google drive credentials between emis server and android app

[Brian Lewis]

Suggestions on data interchange between android app and emis server using google drive

[Ghislain Hachey]

Closing this. It was cleaned up into the software requirements specification document available at https://drive.google.com/open?id=15pSWU6OxhEJQ1PitJX5O6VXcmStAAD81

[Ghislain Hachey]

Re-including a comment from Brian without specifying the private key since this repo is now public.

Google drive offers two distinct ways for an application to access drive data:

-- the application may access data in a google drive belonging to a user

-- the application uses its own data.

The first model requires an interactive consent from the user owning the drive - google handles this by redirecting the drive request to a browser page. Because this is interactive, it is problematic on the server.

The second method involves the creation of a "service account". This account is represented by a private key shared by google drive with the application in the form of a json file. Ths application signs in using that private key to gain access to its private folders. This model does not provide any UI to examine these files.

Using a "service account", we can share that service account's Json file between the android app and the Pacific EMIS web. This would give both access to the same private drive using the google drive API. The android app can write files to this drive, the web portal subsequently read them back.

Each installation of Pacific EMIS would have its own distrinct service account, and therefore its own distinct data storage. A dummy key can be available for testing purposes, and stored in the repository.

The Web portal could provide a REST endpoint to deliver the private key Json file to the android app. This endpoint would be restricted to system administrators. In other words, on the tablet the user would provide an administrator name and password to configure the android app with access to the private google drive belonging to that system.

The Json key file delivered by the google console looks like this:

‌

{
  "type": "service_account",
  "project_id": "pacific-emis-test-38651",
  "private_key_id": "THE-ID",
  "private_key": "-----BEGIN PRIVATE KEY-----THE-PRIVATE-KEY-----END PRIVATE KEY-----\n",
  "client_email": "[e-mail]",
  "client_id": "CLIENT-ID",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/pacific-emis-test%40pacific-emis-test-38651.iam.gserviceaccount.com",
}

We could extend this file with any other configuration values the android app may need from the web server; e.g.

‌

{
  "type": "service_account",
  "project_id": "pacific-emis-test-38651",
  "private_key_id": "THE-ID",
  "private_key": "-----BEGIN PRIVATE KEY-----THE-PRIVATE-KEY-----END PRIVATE KEY-----\n",
  "client_email": "[e-mail]",
  "client_id": "CLIENT-ID",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
    "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/pacific-emis-test%40pacific-emis-test-38651.iam.gserviceaccount.com",
    "context": "MIEMIS",
    "name": "Marshall Islands Education Management System",
    "contact": "[e-mail]"
}

These extra properties don't affect the google api.

So the flow could be:

-- on the tablet the user selects to "Configure School Accreditation"

-- the user enters the user name and password of an administrator account

---- the android app calls the login REST endpoint and gets the Bearer token

---- the android app puts the bearer token onto the request to (e.g.) admin/googleaccount, and gets back the json file above

---- maybe the Android app can get the school numbers and names in the same way?

So this setup can be done in the central office before the tablets are sent out into the field.

File metadata

Files in the google drive have a 'properties' collection that is a dictionary of <string, string> . It is possible to search on these properties via the API. This may be a useful way to store some metadata about a file; that is retrievable by the web server without opening the file Xml content.

In particular I suggest we use:

schoolNo - the school No as defined in EMIS

dateCompleted - the date / time of the accreditation. This is the same date currently used in the file name, but as a string in format yyyy-mm-ddThh:mm:ss.000Z ie UTC e.g. 2019-04-12T00:08:30.000Z

uploaded: POSITIVE if the accreditation has been successfully uploaded into the EMIS - NEGATIVE if the upload failed, not available otherwise

inspectionId: the ID of the accreditation in the SchoolInspection table. Only present when uploaded = 'POSITIVE'

uploadError: a description of any error that occurred in uploading the file ONLY if uploaded = 'NEGATIVE'

These 3 properties - uploaded, inspectionId, uploadError - will be maintained by the EMIS server, updating the original file on the google drive