This document revisits the basic concepts of Open as App, introduces the architecture of the overall system and elaborates on security concerns.
It is organized as follows.
- App Rendering
- App Creation Process
- App Creation Process with External Cloud Storage Providers
- App Creation Process with On-Premises Data
- Authentication Concepts
Before being able to discuss the architecture of the overall system and related security issues, one needs to revisit the most basic concept of Open as App: the dynamic rendering of spreadsheet-based apps on mobile devices.
Open as App dynamically renders spreadsheet-based apps on the mobile device on-demand when the user starts an app. Two resources are required for this process: 1) a local copy of the original spreadsheet, and 2) an app-specific so called app definition, see Figure 1 for an illustration. The app definition contains descriptive data of the app (name, description, icon, etc.) and provides the mobile device with instructions on how to visualize the data from and interact with the spreadsheet. The app definition does not contain any sensible data, it merely describes the user interface and contains references to segments of the spreadsheet, see Table 1 for an exemplary app definition record. Any data and logic is directly provided by the spreadsheet itself. This provides a clear separation of layout, data and logic. Both, the spreadsheet and the app definition, are synchronized to the mobile device and are combined on-demand when the user starts an app. This not only enables offline access but also allows to independently updated either of both resources.
Figure 1: An app is rendered from the spreadsheet and the app definitions locally on the mobile device.
Any synchronized data is securely stored in an encrypted storage on the mobile device, protected by the user’s credentials and the Microsoft Data Protection API (DPAPI)[1]. The app is compatible with mobile device management systems like MobileIron and BlackBerry Dynamics [2].
Table 1: Exemplary app definition used for rendering a spreadsheet-based app.
| Id | fb864b33-c138-4b16-b582-e6bf25a65895 |
| Name | BMI Calculator |
| Description | Body Mass Index Calculator |
| SpreadsheetUrl | https://data.openasapp.net/fb864b33-c138-4b16-b582-e6bf25a65895.xlsx |
| Layout | …<item caption="Body Height" inputtype="input" contenttype="integer" address="B1">... |
| Owner | apphub@openasapp.net |
| PublishMode (internal, not synced) | private |
| AccessControlList (internal, not synced) | [j.doe@openasapp.net, …] |
The overall Open as App system consists of three main components: 1) the web-based management portal for creating, maintaining and distributing apps, 2) the Open as App player for consuming apps on mobile devices, and 3) the Open as App cloud services wiring both platforms together. The Open as App cloud services can further be sub-divided into three sub-components: 3a) the app creation service, 3b) the app distribution service, and 3c) the Open as App cloud storage.
Figure 2 illustrates the responsibilities of the system’s main components using the example of the three most basic use cases the typical actor roles app distributor and app consumer encounter. Apps are built and published via management portal and consumed via app player. All three use cases involve the Open as App cloud services for creating, storing, and distributing the apps.
Figure 2: Responsibilities of the management portal, the app player, and the cloud services.
Figure 3 provides an in-depth illustration of the workflow of creating and consuming a spreadsheet-based app.
Figure 3: Workflow for creating and consuming apps based on spreadsheets from a user’s local device.
For creating an app, the user sends its spreadsheet to the app creation service where it is processed by Open as App’s patent-pending app creation technology. The user negotiates the desired app layout with the app creation service via management portal in a semi-automatic guided process. It is important to note that app creation service is an isolated service in the Open as App cloud which securely processes the data in-memory. Intermediate results from this service are temporarily and anonymously stored in a secured non-persisting behind-VPN in-memory Redis[3] cache, auto-expiring after a short period of user inactivity and only visible to the active user (secured by a random identifier token only known to the user’s active browser session). No Open as App service and especially no third party is able to access the files provided to the app creation service without an explicit request from the user itself. Furthermore, the files are only used for the app creation process. At no time, data from these files is stored in any persisting location, neither directly nor indirectly. Especially, neither personalized nor anonymous analysis data is derived and stored. Any processing is solely done in-memory. Neither the file itself nor any derived data is ever stored in the cloud. Except, of course, one decides to host the spreadsheet with Open as App in the publishing process described in the following paragraph rather than with third-party cloud storage providers or on-premises. Still, Open as App offers the possibility to design apps by hand and to skip all interaction with the app creation service for an application in maximum security environments[4]. However, this means passing on the patent-pending semi-automatic app creation system of Open as App.
After the user has decided on the final app layout, they can finally upload and publish their app. The spreadsheet is uploaded to the Open as App cloud storage (technically, the spreadsheet is retrieved from the app creation service’s in-memory cache with the file’s random identifier token only known to the user’s active browser session rather than being uploaded a second time). The app definition including the URL of the spreadsheet is published to the app distribution service. When creating an app with a file from the user’s local device, the spreadsheet is always stored in the Open as App cloud, however, this step is optional. The spreadsheet may also be hosted with external cloud storage providers (as Dropbox, OneDrive, or Google Drive) or even with on-premises servers. See following sections App Creation Process with External Cloud Storage Providers and App Creation Process with On-Premises Data for more on this topic.
After the app has been published, it can be consumed by authorized Open as App users (see Team, User, Groups and Guests for more on the sharing capabilities of Open as App). For this purpose, the Open as App player retrieves the app definition from the app distribution service and a copy of the spreadsheet from the cloud storage. Both, the app definition as well as the spreadsheet are secured by the Open as App authentication and resource sharing system and only accessible by people explicitly authorized by the apps’ administrators (see following section Authentication Concepts for more on this). App definition and spreadsheet are afterward combined for rendering the app on-demand on the mobile device as already described in previous section App Rendering. This separates layout, data, and logic and enables the system to retrieve the spreadsheets from arbitrary data sources like external cloud storage providers (as Dropbox, OneDrive, or Google Drive) or even on-premises servers, allowing Open as App to be used without having to store sensible data in the cloud. This topic is elaborated in the following sections App Creation Process with External Cloud Storage Providers and App Creation Process with On-Premises Data.
App Creation Process with External Cloud Storage Providers
As discussed in the previous section, users are offered the possibility to host spreadsheets for their apps with Open as App’s own cloud storage. However, Open as App also integrates with a variety of third-party cloud storage providers (including Dropbox, OneDrive and Google Drive), allowing users to create apps based on files from their personal cloud storage from supported external providers.
Figure 4 illustrates the workflow of creating and consuming apps with spreadsheets from external cloud storage providers. Due to the modular structure of the Open as App system, this workflow is very similar to the workflow discussed in the previous section. Basically, it only differs in the way the management portal and the app player access the spreadsheet.
Figure 4: Workflow for creating and consuming apps based on spreadsheets from third-party storage providers.
The app creation process starts with the management portal retrieving the spreadsheet to create the app from. The user selects the desired cloud storage provider, authenticates to the platform (usually using OAuth[5]) and selects the file to use. Afterward, the management portal downloads the file into local memory and the app creation process proceeds as if the file was from the user’s local device (especially the interaction with the app creation service stays the same), until the user is about to publish the app. When publishing the app, the spreadsheet is not uploaded to the Open as App cloud storage. Instead, the app definition is directly linked to the spreadsheet’s original location since the file is already available online.
The process of consuming an app essentially stays the same as if the app was hosted with the Open as App cloud storage. It only differs in the way the app player retrieves the spreadsheet. It starts with the app player retrieving the app definition from the app distribution service and downloading the spreadsheet. Instead of retrieving the spreadsheet from the Open as App cloud storage, however, the app player directly retrieves it from the external cloud storage provider. It locates the file, authenticates the user with the external platform if required (usually using OAuth5) and downloads it into its encrypted local storage. Afterward, both resources are combined for rendering the app on-demand as usual.
App Creation Process with On-Premises Data
Just like Open as App can be used with external cloud storage providers (as discussed in the previous section App Creation Process with External Cloud Storage Providers), Open as App can also be used with on-premises servers (like SharePoint on-premises installations). Besides of the location of the server this approach does not differ from the one described in previous section. Please refer to previous section App Creation Process with External Cloud Storage Providers for details on this approach.
Spreadsheets can be hosted on-premises, solely the app definition - not containing any sensible data - is still hosted in the cloud with the app distribution service. Management portal as well as app player directly retrieve the spreadsheet from their original location and do not require any interaction with a cloud service for doing so. Therefore, spreadsheets may be hosted on-premises just like they can be hosted with external cloud storage providers. Since both systems run on the user’s local device (the app player is a native mobile app and the management portal is a pure JavaScript application running in the user’s local browser), it is even possible to run apps based on spreadsheets securely stored with on-premises servers behind private VPNs – the server is not required to be accessible via public IP. Open as App provides maximum data security with this approach - app distributors have most fine-grained control of their apps since they have full control of their data. It is technically impossible to run apps if their spreadsheets cannot be accessed. Therefore, withdrawing access to a spreadsheet automatically withdraws access to their apps.
Open as App integrates with any on-premises servers offering files via the HTTP protocol. On-premises files can be secured using basic authentication, NTLM or OAuth. Advanced authentication techniques like Kerberos are in the development pipeline.
User register with Open as App by providing their email address and a password of their choice. Passwords are combined with a salt of at least 64-bit and stored as hashes derived with PBKDF2[6] using at least 10,000 iterations as recommended by NIST[7].
Users are required to confirm the possession of the email address they registered with before being able to use all features of Open as App. Users can start testing and creating apps without confirmation but are required to confirm their email address before being able to accept any invitations in order to prevent illegitimate access to shared apps.
Authentication is based on short-lived HMAC-SHA256 signed JWT[8] tokens. Mobile devices use revocable refresh tokens to get permanent access.
Companies can bring their own identity management. Open as App supports integration of a company’s Active Directory and the like using OpenID Connect and SAML2 protocols.
Email confirmation links are secured with non-expiring HMAC-SHA256 signed JWT tokens.
Invitation links are secured with non-expiring HMAC-SHA256 signed JWT tokens.
Password reset links are secured with short-lived (expiration after 24h) HMAC-SHA256 signed JWT tokens.
[1] Microsoft Data Protection API: https://msdn.microsoft.com/en-us/library/ms995355.aspx
[2] MobileIron: https://www.mobileiron.com, BlackBerry Dynamics: https://en.blackberry.com/enterprise/blackberry-dynamics
[3] Redis: http://redis.io
[4] Coming soon
[5] OAuth: http://oauth.net
[6] PBKDF2: http://www.ietf.org/rfc/rfc2898.txt
[7] NIST Recommendation for Password-Based Key Derivation: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
[8] JWT: https://jwt.io
Comments
0 comments
Article is closed for comments.