Sharing Databases on the Web with Porter Proxy

Xin WangSchool of Electronics and Computer Science

University of Southamptonxwang@soton.ac.uk

Aastha MadaanSchool of Electronics and Computer Science

University of SouthamptonA.Madaan@soton.ac.uk

Eugene SiowSchool of Electronics and Computer Science

University of Southamptoneugene.Siow@soton.ac.uk

Thanassis TiropanisSchool of Electronics and Computer Science

University of Southamptontt2@soton.ac.uk

ABSTRACTWith large number of datasets now available through theWeb, data-sharing ecosystems such as the Web Observatoryhave emerged. The Web Observatory provides an active de-centralised ecosystem for datasets and applications based ona number Web Observatory sites, each of which can run ina different administrative domain. On a Web Observatorysite users can publish and securely access datasets across do-mains via a harmonised API and reverse proxies for accesscontrol. However, that API provides a different interfaceto that of the databases on which datasets are stored and,consequently, existing applications that consume data fromspecific databases require major modification to be addedto the Web Observatory ecosystem. In this paper we pro-pose a lightweight architecture called Porter Proxy to ad-dress this concern. Porter Proxy exposes the same interfacesas databases as requested by the users while enforcing accesscontrol. Characteristics of the proposed Porter Proxy archi-tecture are evaluated based on adversarial scenario-handlingin Web Observatory eco-system.

CCS Concepts•Security and privacy → Distributed systems secu-rity; •Networks → Cloud computing; •Computer sys-tems organization → Cloud computing;

Keywordssecurity, access control, data sharing, proxy, web observa-tory

1. INTRODUCTIONIn the past a few years an increasing number of datasets

have been shared on Web Observatory. Some datasets aredistributed as files and more as databases such as MySQLand MongoDB. While enables users to access (e.g. query)

c©2017 International World Wide Web Conference Committee(IW3C2), published under Creative Commons CC BY 4.0 License.

ACM 978-1-4503-4914-7/17/04.http://dx.doi.org/10.1145/***Add your assigned DOI**

these databases, Web Observatory also protect them fromunauthorised access. Similar to a reverse proxy, Web Obser-vatory 1) hides the addresses and credentials of the under-lying databases; 2) provides an authentication and accesscontrol layer (based on OAuth 2.01) that is independentfrom the underlying databases; and 3) enables authorisedusers to query the underlying databases via an API. How-ever, the Web Observatory API authenticates and commu-nicates with user clients via the HTTP protocol, while manydatabases adopts their own protocols based on the TCP pro-tocol. Since existing programming libraries and applicationsare built around those proprietary protocols, their code can-not be easily reused with the Web Observatory API.

To encourage user engagement and enable the reuse ofexisting application code, we need to expose the same inter-faces as those of the databases shared on Web Observatory inaddition to the Web Observatory API, while not to weakenthe protection of the databases. A TCP reverse proxy can ef-fectively exposes databases while hiding their addresses andcredentials, but it relies on the underlying databases to man-age who are authorised to access the databases. We requirea reverse proxy that can mimic databases’ protocols (forboth authentication and query) and separate access controlfrom the underlying databases. We propose Porter Proxy toachieve this goal.

2. RELATED WORKThe community of users engaging with the Web Obser-

vatory may share their artifacts, datasets (or datastreams)and applications in a variety of ways. For example, someof them may allow other users to download a copy of theirdatasets (in form of files). While another set of users mayshare end-points to their databases through which the userscan query the given datasets. The former method thoughsimple to share the datasets but may be expensive in termsof storage required and also not secure. On the contrary,the latter method enables users to access the latest availabledatasets, avoids complicated data exchanges but also raisessystemic concerns for the Web Observatory infrastructure.These include, providing a uniform access interface for au-thentication on the Web Observatory which is compatiblewith the underlying databases.

Addressing this issue is important as, in contrast to lim-ited number of databases available, now a data is avail-able through an increasing number of databases. These

1https://tools.ietf.org/html/rfc6749

1673

databases have their own authentication and access proto-cols and can make the re-use of database complex. More-over, it may not be necessary that all of these datasetssupport public access. There are very limited, almost nostudies in the existing literature that directly address theseconcerns. However, draw our related work on web observa-tories, secure and trusted data sharing, lightweight accesscontrol for mobile and cloud environments and we considerthe studies done in the area of heterogeneous authenticationmethods.

Web Observatory is a distributed infrastructure capable ofharvesting, querying, and analysing multiple real-time andhistoric heterogeneous data, whilst providing data ownersaccess control to their resources [1] [2], [3]. A building pillarof the Web Observatory is that access to some datasets canbe restricted for licensing, privacy or other reasons. TheWeb Observatory allows its users to list or host datasets thatare public or private. Access to private datasets is managedby the user who hosts them on the Web Observatory [2].

Datasets on the Web Observatory are in various typesof stores including, SQL, NoSQL, and triple (RDF) stores,non-structured formats such as CSV [2]. Resources can bequeried using the Web Observatory API, which uses aJSON structured query language, and the mappings to thevarious types of data-stores is handled by the Web Obser-vatory API, and processed server-side. Unlike a distributeddatabase architecture which can be considered as a singlelogical database, we wish to provide a middle layer whichprovide a NoSQL like query syntax that uses the Web Ob-servatory API to query multiple data-stores solutions [2].This API acts as a secure middle layer between the datasetlocations, and the end-user connections, whether this be viadirect access on the Web Observatory portal, or via pro-grammatic use via the development of third party applica-tions and visualisations [2], [4].

3. ARCHITECTURE OF PORTER PROXYPorter Proxy adopts a lightweight architecture to sepa-

rate credential management from databases and at the sametime exposes the same interface as the databases it repre-sents, which allows the reuse of existing application code.It manipulates connections between sockets of clients anddatabases at different stages to achieve its goal. As shownin Figure 1, for a protected database Porter Proxy runsan authentication database of the same type, and an au-thentication client that can communicate with the protecteddatabase. Each client is registered as a user of the authenti-cation database and managed by Porter Proxy. Credentialsto access the protected database are securely kept by PorterProxy and only used by the authentication client. Modifica-tions made to credentials at the authentication database (i.e.client credentials) do not affect credentials of the protecteddatabase, and vice versa. When a client initiates a requestto access the protected database, it authenticates againstthe authentication database. At the same time the authen-tication client authenticates against the protected databaseto establish a trusted connection. If both pass the authen-tication respectively, the client socket is detached from theauthentication database and connected to the socket of theprotected database (as shown in the right half of Figure 1).After the sockets switch, TCP packets representing requestsfrom the client are redirected to the protected database.This redirection is transparent to both the client and the

Protected DB

Client socket

Authentication

Auth DB

Protected DB

Client socket

Switch sockets

Auth DB

Auth Client

Auth Client

Figure 1: Porter Proxy architecture.

protected database, and can be easily integrated with inter-mediate functionalities that work with the TCP protocol,such as IP address filtering and load balancing.

4. IMPLEMENTATIONA prototype of Porter Proxy is implemented in Node.js,

which has native support for the TCP protocol and the po-tential to build resilient applications. In the prototype wetake MongoDB as an example, but all other databases canbe supported alike.

This implementation has the following components:

• A database management module that registers databasesand randomly assigns a unique id to each database.Users browse and request access to databases usingthese ids to prevent leaking identities of the underly-ing databases.

• A user management module that provides an interfacefor user to register, authenticate and manage their ac-cess to databases. In addition, users can manage allthe databases to which they have access. When a user(e.g. Bob) is granted access to a database, this mod-ule creates a new user (e.g. Bob:passBob) in the AuthDB and generates a databases address based on thedatabase id, user profile and a random string. The gen-erated address is unique for each user-database com-bination, and it is independent from the true addressof the underlying database. Both the newly createduser credentials and the generated address are shownto the user, as shown in Figure 2.

• The Auth DB, that stores user credentials and au-thenticates user connections. It is worth noticing thatthe Auth DB only cares about whether the credentialsused to establish a connection are valid, but does notknow which database the user connects to. It is notnecessary to use a complete MongoDB as the Auth DBsince only the authentication function is required. Inthis prototype we implement the MongoDB authenti-cation protocol as a standalone component and use itas the Auth DB to reduce resource usage.

• A MongoDB client as the Auth Clien, that holds thereal addresses and credentials of underlying databasesand connects them. This client is implemented usingthe native MongoDB Node.js driver2.

2https://mongodb.github.io/node-mongodb-native

1674

Bob' s DB Pr of i l e

I D User name Passwor d

001 Bob passBob

Addr ess

mongodb: / / Ym9i MDAxYWJj . ppr oxy. com

. . . . . . . . . . . .

Al i ce' s MongoDB

Addr ess: mongodb: / / db. al i ce. meUser : r eadOnl yPass: passr O

Aut h DB User s ( MongoDB)

User name Passwor d

Bob passBob

Figure 2: An example user profile demonstrating theunique database address and credentials generatedfor each user-database combination. In the profilethe ID column refers to Alice’s MongoDB; Entriesunder Username and Password are registered in theAuth DB.

• A connection coordination module that manages 1) theconnection and authentication between a user clientand the Auth DB; 2) the connection and authenti-cation between the Auth Client and the underlyingdatabase, and 3) reconnects the user client to the un-derlying database after authentication. The coordi-nation module resolves an alias database address toretrieve the id of the underlying database, and thenresolves the database id to its real address and cre-dentials. It is the only module that know which userconnects to which database.

One challenge we encounter is at the implementation ofthe MongoDB authentication protocol. MongoDB supportsseveral authentication mechanisms, and SCRAM-SHA-13 be-comes the default one after MongoDB 3.0. In a SCRAM-SHA-1 conversation the client and the server exchange fourmessages (two round trips) that involve several hashing andverification. MongoDB serialises the SCRAM messages intobinary data and transports them along with some metadata(such as a conversation id) over the TCP protocol4. Sinceevery message is transported as several TCP data chunks,we need to trace the start and end of each message andreconstruct it from data chunks. The first 4 bytes of a mes-sage gives the total length of the message in bytes. Weimplement a buffer to store all received data chunks. Inthe beginning we wait until there are 4 bytes data to calcu-late the total length of the message. Once there are enoughchunks (the size of all chunks is equal or greater than thetotal length of the message) we recover the message and re-move consumed data from the buffer (it could be that a datachunk is partially consumed and only the consumed part isremoved). By repeating the above procedure we manage torecover SCRAM conversations from TCP data stream.

3https://docs.mongodb.com/v3.0/core/security-scram-sha-14https://github.com/mongodb/specifications/blob/master/source/auth/auth.rst#scram-sha-1

5. USE CASES OF PORTER PROXY

5.1 Sharing a MongoDB with Porter ProxyAlice wants to share a large volume of social network data

in a MongoDB so colleagues can query her data. Alice fol-lows two steps: 1) she creates an read-only account (read-Only:passrO) in her MongoDB; 2) she provides the creden-tial of the read-only account and her MongoDB’s address toPorter Proxy. Porter Proxy sets up the Auth DB and theAuth Client internally.

Via Porter Proxy Bob requests permission to query Al-ice’s database. Porter Proxy asks Alice for approval. Onceapproved, Porter Proxy creates an account (Bob:passBob)in the Auth DB, and gives Bob the credentials and an aliasaddress to Alice’s database (in his profile). Bob can con-nect to Alice’s database with a MongoDB client with theinformation in his profile.

5.2 Updating Existing ApplicationsBefore registered with Porter Proxy, Alice’s MongoDB are

used by a few internal applications (whose credentials aremanually managed by Alice). Similar to Bob, owners ofthese applications can request access to Alice’s MongoDBfrom Porter Proxy and find the generated credentials andalias addresses from their profile pages. By only updatingthe database credentials and addresses used in their appli-cation code, these applications would function as normal.

5.3 Building Applications with Porter ProxyAlice’s data (in the MongoDB) turns out to be useful not

only internally but also among users outside her institute.As the MongoDB is on Porter Proxy, external users canfollow the same procedure to request access to the Mon-goDB and have their own unique database credentials andaddresses. Since Porter Proxy exposes the MongoDB withits own interface and protocol, users can build their appli-cations using existing database drivers, libraries in differentprogramming languages. They do not need to learn newAPIs and write data retrieval functionalities from scratch.

6. CONCLUSION AND DISCUSISONIn this paper we describe a lightweight architecture called

Porter Proxy to enable securely sharing databases on theWeb. Porter Proxy exposes the same interfaces as the un-derlying databases to enable the reuse of existing applica-tion code, and separates access control from the underly-ing databases to reduce credentials management cost. Weimplement a prototype of Porter Proxy in Node.js and wedemonstrate and evaluate Porter Proxy using several usecases.

Porter Proxy can encourage users to share databases inan easy and secure way, and improves the ability to buildanalytics in a decentralised manner. Based on the samesockets manipulation technique we work towards generalis-ing Porter Proxy to incorporate various access control andauthentication mechanisms and integrating it with commonproxy functionalists. On the Web Observatory platform itallows for the reuse of applications developed using nativedatabase APIs.

Nevertheless, there are challenges and trade-offs that needto be considered. On the one hand, programmers can de-velop applications using existing libraries based on nativedatabase APIs, on the other hand it does not encourage the

1675

exposure of data resources using harmonised HTTP APIsthat can be used by pure client-side web applications. It ispossible that both approaches will be accommodated on theWeb Observatory ecosystem: data resources will be exposedvia native database APIs (using architectures such as PorterProxy) and via harmonised HTTP APIs at the same time.

7. REFERENCES[1] Aastha Madaan, Thanassis Tiropanis, Srinath

Srinivasa, and Wendy Hall. Observlets: Empoweringanalytical observations on web observatory. InProceedings of the 25th International ConferenceCompanion on World Wide Web, WWW ’16Companion, pages 775–780, 2016.

[2] R. Tinati, X. Wang, T. Tiropanis, and W. Hall.Building a real-time web observatory. IEEE InternetComputing, 19(6):36–45, Nov 2015.

[3] Thanassis Tiropanis, Wendy Hall, Jim Hendler, andChristian de Larrinaga. The web observatory: a middlelayer for broad data. September 2014.

[4] Thanassis Tiropanis, Xin Wang, Ramine Tinati, andWendy Hall. Building a connected web observatory:architecture and challenges. June 2014.

1676