The Science Mesh recently published a demonstration of a procedure to establish trust between users from various sites federated in the Science Mesh. It allows the users to share resources such as file and folder access or access to applications. While the demonstration is quite technical, a graphical user interface is not yet available for the functionality - the operations can be performed through a command line interface, as demonstrated in the demo video available below.
How to create trust between users without previous knowledge?
The core of the sharing functionality upon which resource sharing is built is the OpenCloudMesh application programming interface (OCM API). It defines the protocols that create and retrieve shares, as well as send and retrieve notifications. The OCM API expects the authentication to be already established between the sites/users, which in practice is rarely the case for the users to know each other’s identities in their respective sync and share systems. We need a discovery mechanism for the users to establish a trust relationship using a communication channel they already use.
The technical innovation behind sharing, application access, and access to resources in the Science Mesh
The OCM API allows sharing based on one-to-one configurations among the systems. This is not sufficient in order to build a scalable infrastructure, and a federated solution is necessary. For that purpose, there is a single central entity in our design, the Configuration Database (CD), which holds the metadata which describes the structure of the Science Mesh. Plus, each end EFFS is equipped with an Executive Module (EM) that provides the communication machinery needed in establishing trust between users and sharing resources, and works as well as a service discovery interface for the users based on the centrally managed Science Mesh metadata. This allows for easily adding sites into the infrastructure, while retaining variability of setting user privileges and system reachability.
Using this technical substrate, three basic workflows were defined:
- User Invitation Workflow: which provides a GDPR and user-friendly discovery mechanism of user identities (based on communication through a side-channel such as e-email or instant messaging between the users, see more info in the next section);
- Group Workflow: where a user can delegate group management onto a representative of users of a target system;
- Application Workflow: when a user needs to access data from a Science Mesh-enabled application and the user intends to use a remote application (e.g. a collaborative editor running at another site).
The User Invitation Workflow – the demo
Let us consider an example: there are two users of Enterprise File Sync and Share (EFSSs): Miroslav who uses CESNET’s ownCloud instance, and Hugo who uses CERNBox. Both the systems run the Interoperable Platform (IOP) Reva in front of them. Reva acts as an abstraction layer between the particular EFSS and the OCM API, regardless of the protocol the EFSS in question uses for sharing.
As it is often the case, Miroslav intends to share some data with Hugo, but has no idea about Hugo’s EFSS, neither about Hugo’s identity on the system. He should be able to establish a “trust relationship” with Hugo without having to do much more than contacting him through some communication medium such as email or instant messaging. As email is still the de facto communication standard and an email address the most likely contact information the users know, this demo depicts sending an email invitation.
Let us suppose that Miroslav wants to share a resource (e.g. a folder) with Hugo. Miroslav does not have to know Hugo’s system nor ID in the system. Miroslav uses the “share through Science Mesh” in his own system (here CESNET’s ownCloud) to send an email invitation to Hugo. Hugo receives the email containing a link to the WAYF component of Miroslav’s system IOP. Hugo opens the link and is provided with a list of Science Mesh sites to choose from, similar to a list of identity providers in federations, Hugo chooses the site where he possesses an account (here, CERNBox) and logs into it. During this procedure, Hugo’s user ID in the system is revealed by CERNBox to CESNET’s ownCloud. At this point, everything to establish trust relationship between Miroslav and Hugo is known: both systems and user IDs are there. Tokens are exchanged between the two systems (Hugo’s system contacts Miroslav’s one via a public endpoint and produces the original token there to show the legitimacy of the request) and trust between Miroslav and Hugo is set. Sharing the resource can be done after trust is established between the users. Miroslav can now create a share for Hugo.
The Science Mesh Federation
The Science Mesh federated infrastructure will be based on EFSS installations, aiming to reach a technology readiness level (TRL) of 9, that is, it will be an actual system proven in operational environment. This will allow enable controlled group sharing, data replication and other resource access throughout a set of heterogeneous EFSSs.
In addition to the technical aspects around Science Mesh’s establishment and operations, administrative and governance procedures must also be defined. The goal is to make the governance structure as simple as possible and to limit bureaucracy to the necessary minimum. The Science Mesh will more likely be defined in a Constitution describing the purpose of the infrastructure, governing bodies, requirements for the sites to join the mesh, joining and leaving the Mesh, resolving violations, dispute resolution procedures and procedures to update basic Science Mesh documents.
Last but not least, to ensure operational excellence of the Science Mesh, each participating site will be asked to fulfil certain technical requirements which shall ensure smooth operation and high availability of all its services. To join (and to stay in) the Science Mesh, a site will be required to run various essential services (some of them yet to be determined due to the early nature of the project) necessary to operate within the mesh. While each site is responsible for its own administration, it must provide technical contact information that can be used by the central administrative body to reach out to it in case of technical questions or problems. Furthermore, every site needs to offer extensive support in the form of a helpdesk end users can use to seek for help. Proper operation of the Science Mesh is ensured by constantly monitoring and checking every site and its services externally. This also means that a site may only join the Science Mesh if all services are running correctly, which is verified upfront by the central administrative body during a test phase before a site is added to the Science Mesh.
What lies ahead?
Graphical user interfaces and full integration with the existing EFSSs products will be needed for widespread adoption of the platform and usage by common users. These are tasks which will be addressed in the coming months. Plus, it is essential to ensure that the security of the system will be flawless. All partners joining the Science Mesh must be confident that they can trust the components to be secure and are not increasing the attack surface of their already existing systems (future mesh nodes). To ensure that all the newly developed parts of the project are state of the art security-wise, a penetration test is planned for the first half of 2021. With respect to security aspects of a federated EFSS infrastructure, an assessment will be performed and reported on.
Regarding the European Open Science Cloud (EOSC), where the Science Mesh will be available to link different communities and enable them to collaborate, an integration plan of the Science Mesh within this pan-European initiative will be delivered. More detailed investigation is being done with regards to certain technical aspects, such as how users of the EFSS services under the umbrella of the Science Mesh can share resources amongst themselves, as well as how users who do not yet have access to any institutional EFSS services can have access to the Science Mesh.
