This article discusses the strategy for some third-party cloud service integrations in LiveTiles via Cloud Elements - a web API unification service. This article specifically articulates the strategy used by the Cloud Document tile as of December 2016, but likely to expand in the future toward other third-party B2B third-party services (EG, foreseeable integration in the CRM, Marketing, or Finance space). This article is intended to provide detail to an IT audience, especially those evaluating LiveTiles around security.


The Cloud Documents Tile allows users to display data from variety of file storage services (such as OneDrive and GoogleDrive) in their LiveTiles page. It does so through the concept of integrations, which represent a single authentication instance that a user has made against the corresponding service. All of this is performed from the Integration Manager dialog on the LiveTiles Design home page. For all of this to work, authentication must take place in several steps for a number of various operations. All current operations that require this are listed here. As of now, all supported services implement and make use of the OAuth2 authorization standard.

To start, the process for creating an integration:

  • When the user initially installs LiveTiles to their site collection, the installer creates a dedicated SharePoint list called Cloud Integration Data inside the LiveTiles Design subsite. This list will store authentication information generated later as users create integrations. Only LiveTiles owners will have complete access to this list.
  • After installation, the user navigates to the Add Integration screen for a particular service in the Integration Manager dialog. There, they fill out information such as what the integration will be called, and what SharePoint groups will be able to see and use the integration.
  • Upon adding an integration, LiveTiles Design redirects the user to the Cloud Service Connector web app running in Azure, passing it as a query parameters the return URL (in this case, the LiveTiles installation’s home page), the user’s license key for identification, and the service name for which the integration will be created.
  • The Cloud Service Connector validates the license key, then requests an authentication URL from Cloud Elements with app registration info for the given service that a LiveTiles developer has already configured. 
  • The Cloud Service Connector redirects the user to the returned URL.
  • The user enters their authentication info into the resulting authentication page, and then submits.
  • The authentication page redirects the user back to the Cloud Service Connector, which sends the authorization code returned in this process off to Cloud Elements.
  • Cloud Elements generates and returns a token, an instance id (instance being their terminology for an integration) and an id for the user. The Cloud Service Connector generates its own id for the integration, and creates an entry in an Azure Storage Table containing this integration id, the user id and the instance id.
  • The Cloud Service Connector redirects the user to the original return URL, bundling in the integration id and token as query parameters.
  • Upon returning to the home page, LiveTiles Design parses the integration id and token parameters from the query URL. It then generates its own internal token id for that token and stores all three of these items as an entry in the Cloud Integration Data list created during installation.
  • LiveTiles Design then modifies permissions on the list entry such that only the SharePoint groups previously configured will be able to read it.

The process for using the token to fetch data.

  • When a user configures a Cloud Documents Tile in the designer, LiveTiles Design will query the Integration Data list for all integrations visible to the current user. SharePoint pulls out all information stored inside each entry, and returns it to the app.
  • When the user selects a particular integration for the tile, LiveTiles Design sends a request with that integration’s token to Cloud Elements, which then responds with data provided by the service. This data gets displayed in the tile.
  • When the user saves the page, the integration’s token id gets stored in the tile’s configuration inside the page file.
  • When the user opens an existing page with a Cloud Documents tile, whether in Design or End-User mode, the loaded tile will query the Integration Data list with token id, and receive back the actual token if the current user has the prerequisite permissions. The tile then fetches data with this token as in step 2.

The process for editing an integration:

  • From the Integration Manager dialog, a user makes the desired edits for a given integration and hits submit.
  • LiveTiles Design modifies the entry in the Cloud Integration Data list that corresponds to the integration.
  • LiveTiles Design then alters permissions for the entry item based on any adjustments that have been made to group visibility.

And lastly, the process for deleting an integration:

  • From the Integration Manager dialog, a user navigates to the integration that he/she wishes to delete.
  • LiveTiles Design sends the integration id to the Cloud Service Connector, whose corresponding entry it deletes in the Azure Storage Table.
  • The Cloud Service Connector then sends a delete request to Cloud Elements with the matching instance id.

All of the above listed apply to the LiveTiles Design SharePoint product. There are a couple particulars that differ in the company’s Cloud product, mostly to do with storage of the integration data. These differences are listed here:

  • Upon returning from the OAuth process, LiveTiles Cloud parses the integration id and token parameters from the query URL. It then generates its own internal token id for that token and stores all three of these items as an entry in the API for your cloud tenant. This is an isolated database hosted in Microsoft Azure using their Elastic SQL Database service, containing only your data and securely encrypted using Transparent Data Encryption (TDE).