Federated Cluster Network Infrastructure with las2peer

Purpose

One of the goals in Layers was to enable SMEs organized in clusters to share public information for learning purposes with their cluster partners in a common federated network, while competition-relevant intellectual property of each cluster member remains protected from access by the other cluster partners. In order to enable Layers Boxes to become part of such federated cluster networks, we conceptually integrated a dedicated las2peer [1] node in every Layers Box. With this integration, we created the possibility to create networks of secured communication and collaboration among federated Layers Boxes, using peer-to-peer (P2P) technology. In order to keep P2P communication among cluster nodes secure, we employ sophisticated encryption schemes for message routing and resilient replicated data storage, distributed across the nodes of a las2peer network.

Description

The general approach of federating Layers Boxes mainly bases on the las2peer framework for distributing community services in a P2P infrastructure. With this approach, multiple Layers Boxes connected in a federated cluster network can join forces while either staying independent in terms of managing own Layers Adapters and thus own URL namespaces or become virtually one by using a common Layers Adapter. In the following, we first describe the basic Layers federation concept and then present a use case story, accompanied by technical explanations of how to realize the discussed cases.

Basic Federation Concept

The baseline for Layers Box federation is depicted in Fig. 1, showing two independent Layers Boxes. Each box hosts its own Layers Adapter and OpenID Connect provider. Each box features one or more las2peer nodes. These nodes in turn can host services and store envelopes with secure access to end-users of this box only.

Figure 1 - Independent Layers Boxes (baseline)

Federation of two or more Layers Boxes simply consists in connecting their P2P ports to an arbitrary bootstrap node in an existing network, as indicated in Fig. 2 (cf. D6.3 [2]). For the first, users of each box can continue to connect to their respective Layers Adapter, access their secured envelopes, and access services on their box, as usual. However, without any need for further manual intervention, the las2peer network allows users of all connected boxes to access the union of all services in the network as well as the union of all data envelopes, yet with secure access protection, including redundant replication across nodes. Users can furthermore collaborate by creating groups of agents across boxes and creating data envelopes accessible to users of these groups.

Figure 2 - Partnered Layers Boxes

With growing trust between the two previously independent organizations, there are two different patterns of closer collaboration. In the first pattern (cf. Fig. 3), the Layers Adapter of one organization becomes the main entry point for all users of the federated organizations. Still, each organization uses its own OpenID Connect provider for authentication and authorization. In the second pattern (cf. Fig. 4), each organization still maintains its own Layers Box, but uses one dedicated box as the cluster main entry point for all users. In this pattern, there is only one cluster-wide OpenID Connect provider and one Layers Adapter in use, while the boxes of individual organizations remain protected behind this main cluster node.

Figure 3 - Master-Slave Layers Box Federation

Figure 4 - Cluster Layers Box Federation

Use Case Story

In the following, we illustrate the Layers Box federation concept along the lines of a simplified example scenario, inspired by the original building and construction scenario “Cross-organisational Learning for Sustainable Construction” (cf. Layers DoW, p.7). An overview of this federated scenario is provided in Fig. 5 below. In the context of this scenario, we highlight central las2peer concepts, in particular secure communication and protected data storage and access, thereby addressing important challenges related to P2P-based infrastructures.

Figure 5 - Layers Box Federation Example Scenario

Adam is a trainer working for A-Tech, a building company specialized on energy-efficient lighting. A-Tech is organized in a cluster together with other building companies and training institutions. Each organization operates an own Layers Box, and all Layers Boxes are federated with each other in a P2P network. Adam uses A-Tech’s Layers Box, in particular its company-developed A-Learn las2peer service to create a detailed course including secret company knowledge for A-Tech’s internal apprentices. For all external apprentices in A-Tech’s cluster, Adam uses the same service to create an introductory course without any company-critical details.

Adam opens the A-Learn Web application, a frontend to the A-Learn las2peer service, and authenticates to A-Tech’s Layers Box with his OpenID Connect credentials. After successful authentication with OIDC, A-Tech’s Layers Box redirects him to the A-Learn Web application. Internally, Adam’s OIDC identity is transferred to a las2peer user agent on the las2peer node in A-Tech’s Layers Box.

Any las2peer agent is described by a unique identifier and owns a public/private key pair for asymmetric encryption. Agent information is stored in las2peer’s distributed hash table (DHT) and is thus accessible from every other node in the same network. The information about an agent’s private key is however only accessible to the agent himself in case of a las2peer pass phrase-protected agent or to the members of a group in the case of a las2peer group agent. All human actors (e.g. Adam) as well as Web services can be modeled as las2peer pass phrase-protected agents. Groups such as A-Tech apprentices or cluster apprentices are modeled as las2peer group agents. Both basic las2peer agent types store the private key as direct part of agent information. For pass phrase-protected agents, the key is encrypted symmetrically with a key derivable from a pass phrase only known to the owner. This method is used for the storage of keys in common Secure Shell (SSH) client implementations. For group agents, the private key is encrypted with a symmetric key, and this symmetric key is encrypted asymmetrically to be readable by each member of the group. As illustrated in Fig. 6 (a), all encrypted keys are then stored along with the group information.

Figure 6 - las2peer Encryption Scheme

Adam then interacts with the A-Learn Web application to create two courses and to assign respective access rights for internal and external apprentices. Adam’s requests to the A-Learn Web service including OIDC tokens are first routed to the las2peer node hosting the A-Learn las2peer service through the Layers Adapter of A-Tech’s Layers Box.

In las2peer, Adam’s interaction with the A-Learn Web service translates to a message exchange between Adam’s las2peer user agent and the A-Learn las2peer service agent. All message exchange between participating agents is realized with strongly encrypted envelopes using agent ids for addressing and agent keys for encryption. Message delivery is transparently realized with las2peer’s underlying P2P framework FreePastry (missing reference). Messages may contain any size of data. las2peer therefore applies the much faster symmetric encryption to message contents and encrypts the key for reading the message with the public key of the recipient. Fig. 6 (b) demonstrates this kind of a message envelope sent by Adam to another agent Eve.

Adam’s two courses are represented by two data envelopes stored in las2peer’s DHT. In las2peer, storing data is similar to sending messages. The main distinction is, that a message envelope has only one recipient, while a data envelope may be readable by multiple agents – either normal agents or groups. Furthermore, a message envelope is not subject to persistent storage in the DHT. As shown in Fig. 6 c), the content of a data envelope is again encrypted with a symmetric key, which is then encrypted to be readable by each of the entitled agents. The data envelope displayed in Fig. 6 c) shows a content directly readable by Adam, but also by Eve as member of the group in (a). In order to control access to his two courses to A-Tech apprentices and all cluster apprentices, Adam models these two groups as las2peer group agents and assigns these group agents to the course data envelopes accordingly.

Eve, an apprentice working for E-Build, a construction company in the same cluster with A-Tech, wants to take Adam’s new course via E-Build’s E-Learn Web application, which is partially powered by A-Tech’s A-Learn service. She therefore navigates to E-Learn and authenticates to E-Build’s Layers Box with her OpenID Connect credentials. In the same vein as for Adam, Eve’s identity is transferred to a las2peer user agent on the las2peer node in E-Build’s Layers Box. However, Eve’s user agent now transparently communicates with the A-Learn service residing on the las2peer node in A-Tech’s Layers Box over the P2P network. Notice that while using E-Learn, Eve uses the Layers Adapter at E-Build’s Layers Box and does not explicitly contact A-Tech’s Layers Box. Since Adam’s introductory course is stored as a data envelope in the las2peer network-wide DHT, and Eve is a member of the cluster apprentices group registered in the data envelope’s access control section, Eve can also access it. However, Eve cannot access Adam’s detailed course, since she’s not member of the las2peer group for A-Tech’s internal apprentices.

The scenario described above reflects the partnered Layers Boxes pattern (cf. Fig. 2). With successive increase in trust among A-Tech and E-Build and potentially more companies, progress to Master-Slave or Cluster Layers Box patterns allows to build more dense clusters (cf. Fig. 3 and Fig. 4) and thus scale up communication and collaboration from an infrastructure viewpoint with the help of las2peer technology.

Provided Services

The las2peer-based Layers federation framework does not provide any particular services. It rather serves as a foundation for building up cluster networks of Layers Boxes and making the union of all hosted services on all boxes accessible in a secure and reliable manner.

Scaling and Integration

With the presented federation approach, we enable the organic growth of multiple Layers Boxes organized in P2P networks to one integrated virtual Layers Box, including the inherent scalability and resilience known for P2P networks.

Material

Links

(see link section for las2peer)

Developers and Contributors

• Dominik Renzel
• Peter de Lange
• Thomas Cujé
• Jasper Nalbach
• Alexander Neumann

References

1. R. Klamma, D. Renzel, P. de Lange, and H. Janßen, “las2peer - A Primer,” Chair of Computer Science 5 - Databases & Information Systems, RWTH Aachen University, 2016-020, 2016. DOI: 10.13140/RG.2.2.31456.48645
2. R. Klamma, I. Koren, P. Nicolaescu, D. Renzel, M. Kravčík, M. Shahriari, M. Derntl, G. Peffer, and R. Elferink, “DevOpsUse - Scaling Continuous Innovation,” Learning Layers Project, Deliverable D6.3/Report 4, 2015.