las2peer

Purpose

las2peer is a distributed, reliable and secure framework for creating community information systems. Its main goal is to provide a fast and flexible way to create services, which may communicate with each other and their users through standard protocols. The used and stored information is handled in a trustworthy way and within full control of the communities. las2peer is suitable for providing content in a secure and scalable way, in a peer-to-peer (P2P) manner, within SMEs and clusters thereof. As such, las2peer serves as foundation for the federation of Layers Boxes.

Description

The early, fast, and wide uptake of WebRTC shows that P2P technology with its inherent support for privacy and data protection can become viable with a reasonably transparent integration into well-established Web technologies. As result of this observation, we developed las2peer as substantial framework for the Layers infrastructure from both methodological and technological perspectives. The las2peer development methodology thereby co-evolved with our understanding of a DevOpsUse methodology. In particular, we found strong cross-fertilization between the las2peer core development process in WP6 and the development processes of las2peer-based services within the same work package, e.g. Requirements Bazaar, MobSOS and Community Application Editor, but also across work packages, e.g. SeViAnno (WP4), OCD (WP5) and EIS (WP5). With the availability of CAE las2peer microservice typical developer tasks can be bootstrapped. CAE can thus be seen as essential contribution towards a comprehensive las2peer scaffolding tool. Most Layers Box services base on las2peer and are thus federation-enabled. The conceptualization of our Layers federation infrastructure uses las2peer P2P technology as an augmentation to the cloud-based Layers Box infrastructure, allowing secure communication and data exchange between SMEs and clusters. In the following, we summarize the main concepts of las2peer, based on prior documentation [1][2][3][4].

Basic las2peer Architecture

The basic architecture of las2peer is shown in Fig. 1. las2peer consists of nodes connected via message exchange and a common data storage. While different kinds of agents register to these nodes to participate in the communication, connectors provide access points for outside applications to use the complete system, additionally.

Figure 1 - las2peer Basic Architecture

The interaction of agents is based on simple message communication throughout the las2peer system. As the main communication point is a node, a message can be sent directly if the sender and the recipient reside on the same node. If the participating agents are physically separated, the message is sent through the back-end structure of the las2peer system. Message sending is transparent, as sending or receiving a message from another agent does not depend on the location of the communication partner. Services are conceptualized as agents understanding messages that encode service method invocation requests. The execution of service methods takes place in a secured execution context.

Nodes, Agents, Groups - Secure Communication & Storage

All communication and agent maintenance is encapsulated into a node. Any node can be used in isolation of a network for service testing and development. In network mode, las2peer features rich support for security and privacy with the following attributes:

• Users (agents) are organized in plain groups.
• Outer group anonymity: neither groups nor its members are known to the world. To gain public accessible groups, we provide a global list of public groups.
• No inner group anonymity: all group members may mutually know each other.
• Group administration: only the group administrators may edit membership data.

To reach maximum transparency of group memberships, both the new group member and administrator will have to confirm the membership. To keep it simple, las2peer provides two access rights to an object: read and write. To ensure that no participant can read data replicated in the network he is not entitled to, las2peer defines a cryptographic scheme. All acting entities are abstracted into the concept of an agent sending and receiving messages to other agents and storing and receiving objects with the common P2P storage. Each las2peer node can host multiple agents - especially, if it runs a connector mediating for outside users of the system or if several services are started at this node. All las2peer nodes in a network are treated equally, neglecting how many agents are involved.

Each agent is identified by a unique number, his agent ID. Each agent and each group will be associated with a unique public/private key pair for asymmetric encryption and signatures. las2peer distinguishes between two basic agent types: pass phrase-protected agents and group agents. Both types store the private key directly in the information about the agent itself. For the pass phrase-protected agent, the key is encrypted symmetrically with a key derivable from a pass phrase only known to the owner. For group agents the private key is encrypted with a symmetric key, and this key is encrypted asymmetrically to be readable by each member of the group. On the one hand, a group is an agent of the system. On the other hand, it is a special type of shareable object. In the current implementation of las2peer, a group is a simple list of its members, coming along with two public/private key pairs: one for reading and updating the contents of the group itself (i.e. its member list) and one for reading and writing other objects of and for the group. This implementation allows for simple adding of group members by the group creator or other group administrators.

Figure 2 - las2peer Encryption Schemes

As demonstrated in Fig. 2, all encrypted keys are then stored along with the group information. The shown group is readable by both agents, Bob and Alice, as indicated by the unique colors of keys and locks. All public keys will be stored along with other user related data in the underlying P2P object space. For agent keys that should be usable from different nodes, e.g. for the usage by mediators, those public keys may be stored within the P2P net as well. These keys will be encrypted symmetrically with a pass phrase like keys in the Pretty Good Privacy (PGP) system for example.

Communication

The sending of messages inside las2peer resembles sending of messages through other insecure channels. Fig. 3 shows the different styles of agent communication. All participating agents have assigned asymmetric key pairs for strong encryption. Message delivery is transparently managed by the used P2P back-end library. Users only have to put content into an envelope and address it to the designated recipient. Since the message may contain any size of content data, las2peer applies fast symmetric encryption to the content itself and encrypts the key for reading the message with the public key of the recipient. For authenticity validation, las2peer considers message content signatures. Fig. 2(b) demonstrates this kind of a message envelope addressed to agent Alice.

Figure 3 - las2peer Agent Communication

The storage of data is similar to sending messages. However, a message has only one recipient, and a data envelope may be readable by multiple agents – either normal agents or groups. Furthermore, a message is valid only for a specific period and is not subject to persistent storage. As shown in Fig. 2(c), content is again encrypted with a symmetric key, in turn encrypted to be readable by all entitled agents. Multiple signatures may be added to a data envelope, to enable data authenticity verification. The displayed envelope in Fig. 2(c) shows a content directly readable by Bob, but also by Alice, because she is a member of the group shown in Fig. 2(a).

Connection to the Outside

To allow the connection to a las2peer network from outside a P2P context, las2peer features the connector concept. A connector is not part of a las2peer network, but enables use of las2peer service use from outside the network with a mediation concept. The most actively supported implementation is the Web-Connector. It uses a RESTful approach to access the las2peer network and its services. For API documentation, the Web-Connector features built-in Swagger support.

Scaling and Integration

las2peer is the conceptual and technical basis for scaling up Layers technical infrastructure to P2P networks of federated Layers Boxes. The Layers federation concept is discussed on a separate federation page.

Provided Services

As a community service development framework, las2peer provides a set of basic APIs for developing higher-level functionality supporting different stakeholders, incl. end-user learner communities, developers, and researchers of learning tools. Project efforts in WP4, WP5, and WP6 resulted in the following portfolio of basic and advanced-level community services.

• Basic Community Services: a set of common services for community collaboration, e.g. calendar, chat, file sharing

• Community Application Editing: a set of services powering Community Application Editor [5], a visual model-based Web service and application development tool as part of our DevOpsUse methodology

• Community Evaluation & Learning Analytics: a set of services of the MobSOS [6] tool kit for reflection and awareness of community information systems success as part of community evaluation and learning analytics in our DevOpsUse methodology

• Social Requirements Engineering: a set of services powering Requirements Bazaar, a browser-based tool for social requirements engineering as part of our DevOpsUse methodology [3]

• Simple Web-Based Visual Analytics: a set of services powering SWeVA, a Web-based authoring environment for visual analytics dashboards on arbitrary data sources

• Cloud Video Transcoding: a set of cloud-based services for efficient media transcoding

• Semantic Video Annotation: a set of services for multimedia annotation with semantic metadata

• Expert Identification: a set of services around graph-based expert identification algorithms, suited for higher-level recommendation services in SSS

• Overlapping Community Detection: a set of services around graph-based overlapping community detection services, suited for higher level recommendation services

Material

Links

• Official las2peer Website
• las2peer Boilerplate Project (incl. tutorials)
• las2peer Example Service

Developers and Contributors

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

References

1. M. Derntl, R. Klamma, I. Koren, P. Nicolaescu, D. Renzel, K. Ngua, J. Purma, D. Zaki, T. Treasure-Jones, G. Attwell, O. Gray, T. Ley, V. Tomberg, C. Henry, C. Whitehead, D. Theiler, C. Trattner, R. Maier, M. Manhart, M. Schett, and S. Thalmann, “Initial Architecture for Fast Small-Scale Deployment,” Learning Layers Project, Deliverable D6.1, 2013.
2. M. Derntl, M. Kravcik, R. Klamma, I. Koren, P. Nicolaescu, D. Renzel, A. Hannemann, M. Shahriari, J. Purma, M. Bachl, E. Bellamy, R. Elferink, V. Tomberg, D. Theiler, and P. Santos, “Customizable Architecture for Flexible Small-Scale Deployment,” Learning Layers Project, Deliverable D6.2, 2014.
3. 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.
4. 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
5. P. de Lange, P. Nicolaescu, M. Derntl, M. Jarke, and R. Klamma, “Community Application Editor: Collaborative Near Real-Time Modeling and Composition of Microservice-based Web Applications,” in Modellierung 2016 Workshopband, 2016, pp. 123–127.
6. D. Renzel, “Information Systems Success Awareness for Professional Long Tail Communities of Practice,” Doctoral thesis, RWTH Aachen University, Aachen, Germany, 2016 [Online]. Available at: http://publications.rwth-aachen.de/record/667644