Cloud To Cloud: Enabling Content Transfer among Personal Cloud Instances

Buddhiprabha Erabadda, Visitha Baddegama, and Prof. Gihan Dias Department of Computer Science and Engineering, University of Moratuwa, Moratuwa, Sri Lanka buddhiprabha31481@gmail.com, visithauom@gmail.com, gihan@uom.lk ABSTRACT
With increasing globalization, it has become essential to share digital content with various parties. Meanwhile, it is important to preserve confidentiality and have control over how a particular partys personal content is maintained. Although public clouds enable users to share files with anyone, privacy and confidentiality of client data is highly questionable with public cloud vendors as client data lies with external parties. As a result, personal cloud solutions are being introduced so that people can maintain their own clouds and have control over their data. But with personal clouds, it is not possible to share content among cloud instances as they operate individually and separately from each other. Cloud To Cloud is a solution which enables content transfer among two or more personal cloud instances. For the purpose of explaining the feasibility of the solution, we have implemented the solution using ownCloud, the best existing personal cloud solution with many features. The solution can be extended to interconnect any number of ownCloud instances. The same methodology can be adapted to any preferred personal cloud solution.

provider. There is no way of adding preferred services by the user if a public cloud is being used. Among all the problems, the most concerned issue is the loss of privacy and threat to information security as it is required to trust cloud vendors with very critical and important data of organizations. Therefore, the concept of personal cloud is introduced, which overcome the problems stated with public clouds. [1] The main drawback of personal clouds is that intercommunication among different personal cloud instances is not allowed. Users residing on same cloud instance can share files among them, but those transfers are limited to users on the same cloud. To overcome this problem, we have proposed a solution which combines various existing protocols and enables communication among multiple personal cloud instances. To prove the feasibility of the proposed solution, we have selected ownCloud as the personal cloud solution and enabled communication among multiple ownCloud instances. There is a considerable number of personal cloud solutions that are available at present. Some of these are commercial and some others are open source. OwnCloud being a platform independent (as it is browser based) and open source solution enriched with many features, it outperforms all other existing personal cloud solutions. There is a large user base of ownCloud and since it is an open source solution, new features and improvements are added by developers all over the world. [2] The goal of the project presented in this paper is to propose a solution to enable two or more personal cloud instances located at different locations to communicate with each other. We implemented the solution using ownCloud to ensure feasibility.

KEY WORDS
Cloud Computing, file ownCloud, OpenID, rsync sharing, personal cloud,

1. INTRODUCTION Cloud Computing plays a vital role in todays world of information sharing and it will remain the same into the future too. As a result of increasing popularity of cloud computing, the demand for services from cloud vendors has also increased. The problem with public cloud vendors is that users have to abide by the terms and conditions and use only the services which are offered to users by the cloud

ISBN: 978-0-9891305-4-7 2014 SDIWC

28

OwnCloud is an open source software suite that provides personal cloud storage and it is written in PHP and JavaScript. It is operated from a web interface and hence it is not tied to the operating system being used. OwnCloud enables its users to store content such as files, folders, photo galleries, and calendars on a server operated at the users end. The user can then access these contents through a mobile device, desktop or any other device with browser support. With ownCloud, users can sync their files and share data with other users. Although ownCloud has many useful features as mentioned above, it did not have the capability to share content among two or more ownCloud instances. Therefore, it was not possible for a user to download a file which is shared by another ownCloud instance or could not access his own file from another cloud instance. A user could download a file only if the file is being shared by a user from the same ownCloud instance. These issued are addressed by the solution explained in this paper. Following are the two use cases that are being addressed by the project. To have a better idea about the solution that is being proposed, instead of stating the proposal referring to personal clouds in general, majority of the work is stated specifically referring to ownCloud. The same methodology can be used to inter-connect instances of any personal cloud solution which supports adding the protocols and techniques used in the proposal. A. Use Case 1 Two users on two distinct ownCloud instances There can be two users (User-X and User-Y) on two different ownCloud instances (Cloud-A and Cloud-B), with User-X on Cloud-A and User-Y on Cloud-B.) Since the users are on two separate installations of ownCloud, it is not possible to share files between them as per the features of ownCloud. B. Use Case 2 Same user on two ownCloud instances A user can have multiple personal clouds on different locations.(Location-A and Location-B) These accounts may contain different sets of files for the same user. If the user is logged in from the cloud at Location A and needs access to a file at Location ISBN: 978-0-9891305-4-7 2014 SDIWC

B, it was again not supported as the ownCloud installations are different. Both these situations occur frequently in day today life. For example, university-A can have an installation of ownCloud at its premises and university-B can also have an instance of ownCloud. These will be completely distinct from each other. But it may be required to share assignment files of a particular common course between the universities using their two cloud instances. The cloud at the university-A will be completely unaware about users on the cloud at the university-B. Therefore it is required to enable content transfer among users regardless of the fact they are on their own cloud instances which are distinct from other cloud instances. When such content transfer is enabled, all can move from public cloud vendors to personal cloud solutions and still be able to share files with anyone interested. This will ensure that privacy and confidentiality of various files is secured as personal clouds are monitored and maintained by the owners of the files. 2. BACKGROUND The solution proposed in the paper combines existing protocols. Among these, OpenID plays an important part and it is used for authentication among cloud instances. With web technologies that are being introduced, the number of sites that require registration/log-in has also increased. This has forced individuals to keep multiple usernames and passwords in mind. OpenID is a Single Sign-On protocol which solves this problem and enables users to log-in to all OpenID enabled web sites with the OpenID URL without having to remember combinations of usernames and passwords.[3] There are multiple OpenID service providers who act as third parties to authenticate users on behalf of various other web sites. Anyone interested in becoming an OpenID service provider can do so by running an OpenID server. We have used the latter method for authentication so as to minimize intervention of third or external parties. Setting up personal clouds usually mean that users like to have operations in their preferred manner with minimal 29

third party interference ensuring privacy while giving concern to personal interests. Without harming this nature of personal clouds, we decided to set up an OpenID server for each personal cloud installation. There are many open-source OpenID servers that are available. Since we used ownCloud to demonstrate our solution, we used SimpleID as the OpenID server as both are written in PHP. SimpleID supports multiple identities. [4] For the solution, it was also required to transfer files once shared and synchronize them when changes are made. There are many protocols available for file synchronization which are rsync, LBSF (Low Bandwidth Network File System), and TAPER (Tiered Approach for Eliminating Redundancy in Replica Synchronization). Rsync algorithm computes differences among copies of shared files and transfers only the changes so that the data transfer across the network is minimal. [5] LBSF is designed for low-bandwidth networks. It exploits similarities between files or versions of the same file to save bandwidth. It avoids sending data over the network when the same data can already be found in the servers file system or the clients cache. [6] TAPER is a scalable data replication protocol that synchronizes a large collection of data across multiple geographically distributed replica locations. It is designed to be bandwidth efficient [7] Out of the available file synchronization protocols, we used rsync for our implementation with ownCloud. Other better and more efficient protocols can also be used. 3. APPROACH We developed a separate third party application which runs on top of existing ownCloud platform. Interested users can install this third party applications on top of their ownCloud installation once released. As it is developed as a separate application, it does not negatively affect ownClouds core, the existing applications that run on ownCloud and any other features it has.

We interconnected two ownCloud instances according to information detailed below. The procedure used to interconnect two ownCloud instances can be extended to any number of cloud instances. The proposed solution can be broadly divided into two parts. They are Authentication File transfer and synchronization 3.1. Authentication It was required to authenticate between two ownCloud instances as any two instances are separate from each other. This authentication was required because when a particular person is logged in to his/her account in the cloud, and a file is shared to him/her by another person, it is required to prove identity of the first person to the cloud of the second person. This is because a particular cloud has information (login credentials) only about users who are registered at that particular cloud. OpenID was used as the authentication mechanism among the cloud instances. As explained in the previous section, OpenID acts as the Single Sign-On and the users can prove their identities to various sites using the OpenID URL. An OpenID server implemented by configuring SimpleID was added to each ownCloud installation such that when a user logs into his/her ownCloud account, he/she automatically gets logged into the OpenID server that is installed at that particular cloud instance. When another cloud wants to authenticate that user, it can talk to the OpenID server that the user is logged in and verify the users identity. This is made transparent to the user so as to improve usability. Say, user-X on Cloud-A wants to share a file on Cloud-A with user-Y on Cloud-B as depicted in Figure 1. (Rest of the paper will refer to this scenario to make it easy to understand.)

ISBN: 978-0-9891305-4-7 2014 SDIWC

30

Cloud-A

Cloud-B

to the login page of the OpenID server. Once Y successfully logs in, shared files are listed as in the previous scenario. The high level steps of the authentication process are shown in Figure 2 and described below.
Cloud-A Cloud-B

file

User-X

User-Y

Figure 1. Sharing a file with a user on another cloud

According to the approach we adopted, an email is sent to Y mentioning that a file was shared with him by X on Cloud-A. This e-mail contains the URL of Cloud-As public page. The public page of a cloud was created as the access point of external users to the cloud. The users can enter their OpenID unique name (OpenID URL) in this page. Then OpenID protocol runs in the background and authenticates the user by calling to the OpenID server at Cloud-B. Y can get access to the shared file in one of two scenarios mentioned below. Y is logged in to his account on his cloud At this time, Y is already logged into the OpenID server that is deployed with his cloud instance, Cloud-B. When Y goes to the URL of the public page of Cloud-A, he will be notified that Cloud A wants to verify the identity of Y. According to OpenID standards, Y will provide his OpenID URL to Cloud A. This URL contains information about the location of the OpenID server of Cloud-B. Then Cloud A will talk to the OpenID server of Y and since Y is already logged in to his OpenID server in this scenario, his identity will be verified by the OpenID server. The files shared to user-Y from users on Cloud-A will be displayed on the public page afterwards. Y is not logged in to his account on his cloud In this case, after Y provides his OpenID URL, Cloud A talks to Cloud Bs OpenID server to verify the user. Since Y is not logged in, the user is directed ISBN: 978-0-9891305-4-7 2014 SDIWC

file

4 3 Cloud-As public page 5 Cloud-Bs OpenID server

Figure 2. Steps of authentication

The numbering in the figure refers to the following steps of the process. 1 - Sending e-mail to the user with whom the file is being shared. 2 - User-Y accesses the public page of cloud-A 3 - User-Y enters his OpenID user name to the public page 4 - Cloud-A talks to the OpenID server of User-Y to verify identity 5 - Sends authentication success/failure message In the authentication component, there are three parts as mentioned above. They are: E-mail Generator OpenID URL Generator Shared List Generator 31

E-mail generator is responsible for sending the e-mail to the user with whom the file is being shared as a notification. The OpenID URL generator is responsible for creating the full URL to locate the OpenID server. The OpenID URL entered by the user is in the form user_Y@cloud_B_url. This form is used to look like a typical e-mail address so that it is user friendly. From this OpenID URL, the location of OpenID server of Cloud-B is generated by the OpenID URL generator. Shared list generator is responsible for talking to the database and finding the list of files that are shared with the logged in user. This list is then shown to the user, in this case to Y. To keep details about the files shared with users on different cloud instances, a separate table is added to the database. There is a table in ownCloud(named oc_share) which keeps details about files that are shared with users on the same cloud instances. To avoid any possible inconsistency that can take place by adding details of files shared with external users, we decided to add a separate table. The high level architecture of authentication component is shown in Figure 2. 3.2. File Transfer and Synchronization When a user views the listing of files that are being shared with him/her, he/she can decide if it is needed to be transferred to his/her cloud. Referring to the same case mentioned in the previous section, when Y views the list of files shared to him by users of Cloud X, Y may decide that he needs to have the file on his cloud instance, Cloud B. At that time Y has the option to transfer the file to his cloud. To download and synchronize the files, we have used rsync protocol. Thus when a file shared among multiple users is altered by one of the users, those changes will be transferred to others. This is more efficient than re-sending the whole file when it is updated. Since the details of files shared with external users are stored in a table, this table is queried when a change is done to a shared file. Then the

rsync protocol is run to synchronize the changes with others with whom the file is being shared.
OpenID web page Cloud Bs OpenID Server

Files App Cloud To Cloud

a
c

Public Page

Database

a Shared list generator, b e-mail generator, cOpenID URL generator Figure 3. High level architecture of authentication component

4. RESULTS To test the efficiency of the solution Cloud To Cloud, a file of size 50 KB was used and changes were made to the file. The average runtime for file synchronization was calculated and the results are given in Table 1.
Table 1. Average runtime for synchronization when a file is changed

Percentage change 1% 5% 10% 20% 100%

Average M (Ratio of run time Change) (seconds) 0.01 3.345 0.05 0.1 0.2 1 3.503 3.626 3.878 5.593

ISBN: 978-0-9891305-4-7 2014 SDIWC

32

When the rate of change to the file is increased, the rate of average time taken for synchronization is reduced. The reason for this is that the time taken for gathering file information is determined by the file that is used and it is unchanged for different values of M. Therefore the rate changes as M increases. 5. CONCLUSION With the solution proposed in Cloud To Cloud, it is possible to transfer files among users on distinct ownCloud instances. This solution can be extended to interconnect any number of ownCloud instances that are located anywhere in the world. One of the main reasons that people go for public cloud solutions is that they do not have a way of sharing files unless all are connected with a single well known public cloud provider. There was no solution which enabled such content transfer without public clouds. With our solution, that barrier is removed. People always wish to have things in their own way. At the same time privacy and confidentiality of data that are stored at public clouds has been questioned many times. [8] Therefore, people will prefer moving to private clouds completely so that they are assured about privacy and confidentiality as data then lies at their own control. With ownCloud, they can assure the confidentiality but a main purpose of cloud computing, which is sharing, was not present in ownCloud when instances are distinct. This problem is not limited to ownCloud and it is there in all personal cloud solutions. This issue is handled by the solution Cloud To Cloud proposed by us in this paper. Various existing protocols were combined to come out with the solution. OpenID protocol for Single Sign-On was used for authentication among distinct cloud instances. This was a key part of the solution as a shared file should reach only to the intended parties and not to other third parties. We used ownCloud as the personal cloud solution and implemented the proposed interconnecting technique Cloud To Cloud in order to prove the feasibility of solution. The same methodology can be used in any personal cloud ISBN: 978-0-9891305-4-7 2014 SDIWC

solution that supports addition and implementation of stated protocols. If all personal cloud solutions are supported with this, any two personal cloud instances of any type can be inter-connected to support content transfer among them. 6. FURTHER IMPROVEMENTS With the current status of the solution, when a file is shared with a user, he can decide to download the file to his cloud instance. This download is done as a complete download of the file. This download can be further enhanced by using either of the following methods.

Transferring parts of files that are different from an existing similar version of the file Transferring parts of the file when needed (this is dynamic loading. For example, content of the latter part of a document is transferred only if the user scrolls down)

Additionally, in the implemented solution we used rsync as the file synchronization protocol. We used rsync as it was easy to integrate to the solution. However there are many other better protocols that can be used for file synchronization. For example, TAPER reduces bandwidth by 15% to 71% and enables faster matching. [7] There is no open source implementation of the TAPER protocol but the paper provides sufficient information for implementation. Any interested party can try and integrate TAPER instead of rsync to further enhance performance of the proposed solution. These changes can be made in the future to make the application more efficient. 7. ACKNOWLEDGEMENT We are grateful to the members of the academic staff and the non-academic staff of the Department of Computer Science and Engineering, University of Moratuwa, Sri Lanka for their support and guidance for the project.

33

8. REFERENCES
[1] Designing Private and Hybrid Clouds , 2012. [online]. Available: http://www.rightscale.com/info_center/whitepapers/rightscale-white-paper-designing-private-hybridclouds.pdf[Accessed July 2013] [2] The ownCloud Developers. ownCloud User Manual [online] Available: http://doc.owncloud.org/server/4.5/user_manual/ [3] Tony McDonald. Facilitating online integrity using OpenID in ascilite, Melbourne 2008 [4] Ole Kritian Ek Hornnes, Run your own identity server [online] Available: http://wiki.openid.net/w/page/12995226/Run%20your%20 own%20identity%20server [5] Andrew Tridgell and Paul Mackerras The rsync algorithm, June, 1996 [6] Athicha Muthitacharoen, Benjie Chen, and David Mazieres. A Low-bandwidth Network File System", February, 2002. [7] Navendu Jain, Mike Dahli, and Renu Tewari. TAPER: Tiered Approach for Eliminating Redundancy in Replica Synchronization in 4th USENIX Conference [8] Wayne Jansen and Timothy Grance :Guidelines on Security and privacy in public cloud computing, January, 2011 [9] Torsten Suel and Nasir Memon Algorithms for Delta Compression and Remote File Synchronization [10] Brian Adler. Building Scalable Applications In the Cloud: Reference Architecture & Best Practices [online] Available: http://www.rightscale.com/info_center/whitepapers/RightScale_White_Paper_Building_Scalable_Appli cations.pdf [11] RSync Detecting File Differences [Online] Available: http://tutorials.jenkov.com/rsync/detecting-filedifferences.html [Accessed: 11-Sep-2013] [12] SimpleID - Multi user identity provider written in PHP [Online] Available: http://simpleid.koinic.net/ [Accessed:20-March2013] [13] What is ownCloud and how to work with it [Online] Available: http://owncloud.org/ [Accessed: 20-Sept-2012] [14] Demonstration on how ownCloud works [Online] Available: http://demo.owncloud.org [Accessed: 25-Sept2012]

ISBN: 978-0-9891305-4-7 2014 SDIWC

34