The strength of the OPENi platform stems from the three pillars upon which it is built: the Cloudlet Framework, the API Framework, and the Security Framework.
Most readers will be somewhat familiar with APIs and Security. The term ‘cloudlet’, however, might not reveal it’s meaning as readily. Simply put, an OPENi cloudlet provides application consumers with a single location to store and control their personal data.
To treat it more technically, it is a user-centric datastore with privacy-aware access control for cloud-based data platforms.
In conjunction with the security framework, the cloudlet allows application consumers remain in control of their data. Consumers are assured their data is not being used without their consent.
Personal Cloudlet Objectives
Before work commenced, we asked ourselves the following question
How should a secure and privacy concerned web based framework be developed in order to provide user-centric management to dynamic data and APIs, while providing the developer with the ability to access the data in a privacy concerning manner?
To answer this, we set out these key objectives
- To build key technological enablers to ensure the practical applicability and efficient use of the OPENi platform
- To deliver an open source platform that will allow application consumers to create, deploy, and manage their personal space in the cloud (Personal Cloudlet). Each Personal Cloudlet constitutes an entity that will be linked to its user’s identity
- To provide and promote a novel, consistent, user-centric application experience of cloud-based services not only across different devices but also across different applications
- To ensure the OPENi platform maintains a low barrier to entry for application developers and service providers
Building the Pillar
The cloudlet is implemented as a distributed application, composed of a number of software components, called workers, distributed across a number of hardware nodes. These workers communicate with each other by passing messages.
This approach provides several significant features
- Each component can scale independently of each other, depending on the demand
- Components are small and concentrate on a single task
- The overall application is stateless, i.e. none of the core components maintain state/session data
A range of diverse, complimentary technologies have been brought together to realise our vision of the cloudlet
- Mongrel2 (web server that talks HTTP to Browsers on the frontend and ZMQ to micro-services on the backend. It connects the application to the real world.)
- ZMQ (Message Bus)
- JWT (allows for session like requests in a stateless system i.e. a public/private key setup where only the auth component has the private key, and other components have the public key.)
- Swagger (makes it easier to develop REST endpoints via auto generated HTML pages which interact with the endpoints and also create SDKs)
- CouchBase (NoSQL Datastore)
- JSON (data format, used in transport and at rest)
- Micro-services/distributed application
The View from the Top
The data storage component is capable of storing user, app-specific, and internal cloudlet data. This data may be in various forms such as text, graphical, audio etc. Consequently it is capable of accommodating binary files as well as structured JSON data.
All data that exists in a cloudlet will be accessed via the Data API and the Type API. They ensure a consistent access point for all services such as apps, the API framework, and 3rd party services. In conjunction with the Authentication, Authorisation, Accounting component and permissions, the cloudlet owner is in full control of who and what can access each piece of data in their Personal Cloudlet.
To empower Cloudlet owners in the management of their cloudlets they have a standalone GUI, separate to the on app interface. GUI features include:
- access logs viewing
- preference editing
- permissions editing.
User Centricity & Privacy Preservation
JSON Web Tokens (JWT) are digitally signed, base64 encoded JSON objects, that enable stateless REST based frameworks to manage sessions and claims. In the Personal Cloudlet Framework, we extended the use of JWTs to also manage the context of the party accessing the users data.
In OPENi, multiple 3rd parties request data using the same endpoints but are presented with different subsets of user data dependent on user permissions. JWTs enable this data masking in accordance with an OAuth 2.0 compliant workflow.
All Personal Cloudlet data is persisted to a NoSQL document store; accordingly, a users Personal Cloudlet is composed of a number of JSON objects. OPENi Types are in place to expose the structure of the JSON objects without revealing the objects content. All OPENi Types are public and app developers are free to either create their own or reuse those created by others. To further promote Type reuse the platform provides a Registry which describes existing types and and also gives an indication of a type’s popularity.
The Personal Cloudlet Framework controls data access by attaching permissions objects to each individual Object within a cloudlet. Each permissions object lists approved apps and whether the approved app can create, read, update, and delete that object. When an app calls the object API these permissions rules are checked before the API call is acted upon.
We are inextricably bound to our identities. The modern web has seen us compartmentalise aspects of ourselves, divvying up parts of our digital identity for various cloud-based services and applications. At a fundamental level, this weakens us. We are eroding. Our digital self is no longer whole, and that separation results in a loss of value in our personal data.
The OPENi Cloudlet offers a solution to this digital disconnect. By providing users with a single location to store and control their personal data, we are neither merely catering to them, nor are we simply hoping to attract them, instead we are empowering them.