Federated Cloud Sharing | News

The Federated Architecture of Next Generation File Sync and Share

In my last blog I introduced the concept of federation as the solution to the biggest limitation that second generation clouds suffer from: the difficulty of cross-cloud collaboration. In this blog I will describe the architecture of a federated file sync and share cloud, and where ownCloud is in building the infrastructure for the future of sync and […]

generation 2In my last blog I introduced the concept of federation as the solution to the biggest limitation that second generation clouds suffer from: the difficulty of cross-cloud collaboration. In this blog I will describe the architecture of a federated file sync and share cloud, and where ownCloud is in building the infrastructure for the future of sync and share on the cloud.

Architecture

Let’s start with the architecture of the federated cloud. The federated sharing specification is built on two REST/http -based public APIs that are accessible over the internet. The first is the well known and widely used WebDAV standard which we use for the actual file transfer. The second part is a simple REST API to initiate federated sharing and exchange metadata. The specification relies on https/SSL/TLS for security.

WebDAV

The file transfer API is based on the standard WebDAV protocol. WebDAV is a well established API which is available for easy implementation and integration on virtually every platform. This choice lowers the barrier to adoption of federated file sync and share by other cloud technologies. A few extensions are needed for performance improvements, described in our specification. Authentication is done via sharing keys that are passed as http basic auth.

Federation metadata

The second API is a specific federated sharing API that is used to initiate sharing requests and exchange metadata and process data. If a sharing request is accepted or denied by the user on the second server, the accepted or denied codes are sent back via the API to the first server. Part of a sharing request is a sharing key which is used by the second server to access the shared file or folder. This sharing key can later be revoked by the sharer if the share has to be terminated.

The complete API specification will be available as a public API draft for discussions. We would like to implement this API as an open federated sharing standard that can be implemented by different file sync and share services and providers. Any cloud servers that want to support federated sharing can implement these two API’s and should then be able to talk to each other.

Next steps

generation 3The federated cloud sharing API specification will be published in the first half of 2015 with the goal of starting an open discussion. We hope that other cloud vendors implement this API so that the users can collaborate and share between different services. A fully functional implementation of this standard is already part of ownCloud 8 which was released in Q1 of 2015.

Federated clouds are an extremely powerful concept that a lot of users and administrators will love. It combines the ease of use and the seamless collaboration of centralized and consumer-grade cloud file sync and share services with the security, flexibility and control of self hosted on premise services.

We expect that the current version will quickly become popular over the next six months. But we see this only as the first step. A lot more work will be invested into this concept by ownCloud and others in the next months and years and we expect to see a lot of new and exiting use cases that will be built on top of this concept.

So be sure to check back next week to learn even more, as I will be publishing a draft of the API specification.

This Blog post is part two of our Federated Cloud series. You can find the other parts here:
Part 1: It is time to Federate our Clouds
Part 3: Announcing the Federated Cloud Sharing API

ownCloud GmbH

July 28, 2015

Read now: