Team 36 PEACH Project

Ever since the beginning of the project, our main focus was to conduct an online research in order to assimilate the new concepts and to find more details about our objectives, possible approaches and current technologies.

After defining clear requirements for the authentication and RBAC component part of the app, it was clear that we need to find the best available tools in order to achieve the desired functionality. We, therefore, started researching about authentication methods or frameworks that we might use, while also looking into some role-based access tools that we could have used. To define the requirements clearly for the internal messaging system, we made researched the existing technologies which could possibly be used in our project and we also explored some of the existing messaging systems as an initial step.

To define the requirements clearly for the internal messaging system, we made researched the existing technologies which could possibly be used in our project and we also explored some of the existing messaging systems as an initial step.

Ever since the first meeting, our client stated that a collaborative text editing tool is needed for our project. The aim is to build an independent component which can be easily integrated in other multiple templates or auto-generated content pages. Besides the basic function where multiple users can contribute to the text at the same time, the tool should also provide more options, such as a pointing to the cursor of each participant, formatting the input text or saving the data in the end.

Frameworks/ platforms taken into consideration

The first thing to do was to find an actual authentication framework to use. We also had to keep in mind that security was a top priority, so the possibility to build our own authentication, without using a framework dropped, since we could not provide the level of security needed. The client recommended to check Apache Shiro since he thought it might be a good idea. After taking a look at it, it seemed like a good solution, since it provided very important tools such as: authentication, authorization, cryptography and session management. It is also regarded as one of the most secure on the market which was a huge plus. [1]

Now, the only issue was that we were not sure what Role-Based Access Control tool to use. So, we tried to look for a solution that would be simple enough and easy to integrate in our back-end. The first option was OpenIAM, a free tool that provides basic RBAC features [2]. It seemed easy to use and that it might be an available option. However, no specific integration with Apache Shiro was available, so we were not sure if we should consider it.

By searching more, I actually found out that Apache Shiro “provides out-of-the-box realms for popular data sources like Active Directory” [3]. So, having this is mind, we actually decided that using Azure Active Directory might be easier to use and the client agreed. So, the next step, in order to make sure that everything will go smoothly, was to actually test how Active Directory is behaving. For that, we conducted a series of experiments (which can be found in the ‘Experiments’ section of the website) in order to see how easy it is to create, access and manage user roles within Active Directory. It resulted that it is quite easy by using their CLI or Rest API in order to send different type of requests [4].

However, I also considered Keycloak since it had a very good administration console, which was highly customizable and has great support for user roles and management. Moreover, it adds a lot on top of Shiro, especially by providing template user interfaces that can be used [5].

Final platform chosen

After carefully analysing all the available tools and frameworks described above, we decided to finally Keycloak. This was mainly because it is very customizable and provides easy to use administration functionalities, from adding users to require email verification and setting temporary passwords.

Languages taken into consideration

Initially, we thought about using JavaScript within a Node.JS solution as a possible solution, but we realised from the first set of requirements and from the discussion with the client that we needed to use more complex tools to achieve what it was wanted. Therefore, as research advanced, a new set of Java Authentication Frameworks (which were mentioned above) seemed very good for us, so Java became another option to think about. Finally, we also thought about PHP, since we had experience in it and it was easy for us to use.

Final languages chosen

Since we have chosen to use Keycloak, we therefore used Java for the authentication system as the main language for our back-end, while the front-end remained classic (JavaScript, HTML, CSS).

Strenghts of Keycloak

Keycloak is a very powerful and amazing tool, which comes with an incredible set of functionalities, such as a customizable admin portal or the option to easily secure applications within Java realms. It can be set up based on preferences and it has almost everything we needed to accomplish our requirements, from very good security, to defining and managing user roles.

Weaknesses of Keycloak

However, Keycloak has a huge downside in our opinion, this being the fact that the documentation seems very poor or hard to find, which resulted in some early stage problems. Moreover, the customization of the front-end was not very easy to do within the framework, due to the huge number of files within the Keycloak standalone server.

Final Solution

As our final solution for the authentication system, we have used a Keycloak standalone authentication and authorization server. We decided to install it on an Azure VM, from where it can handle everything relating users and admin console preferences.

Furthermore, we thought it would be great to enable 2 types of logging in: OpenID Connect (OAuth) for 3rd party apps and simple logging in for apps registered under the Keycloak server. In this way, a variety of PEACH apps (and others) can benefit from the user details if they have the required permission.

Moreover, we planned to use PostgreSQL with Keycloak since they work well together and there is enough documentation online to make this possible.

References
[1] Apache Shiro. Simple Java Security. www.shiro.apache.org [Online]. Available: https://shiro.apache.org/ [Accessed: 10 December 2016]
[2] RBAC - OpenIAM - Identity and Access Management. OpenIAM - Identity and Access Management. www.openiam.com [Online]. Available: http://www.openiam.com/products/access-manager/features/rbac/ [Accessed: 10 December 2016]
[3] Apache Shiro. Authentication Features - Apache Shiro Authentication Features. www.shiro.apache.org [Online]. Available: https://shiro.apache.org/authentication-features.html [Accessed: 10 December 2016]
[4] Microsoft. Azure Active Directory – IAM Solution. www.microsoft.com [Online]. Available: https://www.microsoft.com/en-gb/cloud-platform/azure-active-directory [Accessed: 10 December 2016].
[5] Keycloak. Keycloak - Documentation. www.keycloak.org [Online]. Avaiable: http://www.keycloak.org/documentation.html [Accessed: 1 February 2017]

Frameworks/ platforms taken into consideration

After deciding to use an open-source chat platform, the research that we had done so far helped us to choose the most convenient platform which was Rocket.Chat among a wide range of platforms that we considered [6] – [15]. Considering the unofficial requirements that we gathered from our client, our finalists were Mattermost, Zulip and Rocket.Chat [6], [7], [10]. Mattermost was a very good platform which uses Golang and React with MySQL or Postgres [7]. However, it was not fully open source and our client had to pay for some of the features that they may require in the future such as multi-factor authentication and chat-bot integration [7]. Zulip was also a good chat platform with many features and it was written in Python [10]. It was less Slack-like than Rocket.Chat in terms of GUI and chat-bot integration capabilities and our client mentioned multiple times that he wanted a chat-bot integration [6], [10].

Final platform chosen

Rocket.Chat was the best platform for our internal messaging system considering it was the only platform that had chat-bot integration, they even had a chat-bot in beta version, its features such as real-time messaging, group chat and file sending [6], [16], [17]. It was also making use of Node.js which we had recently experienced and we had positive opinions about it. It was also using Meteor full-stack framework extensively and it was using MongoDB as database due to its compatibility with Node.js [5], [6], [16], [17]. The other technologies that Rocket.Chat makes use of are HTML, CSS, JavaScript and jQuery for front-end [16], [17]. It also uses numerous npm (node package manager) dependencies such as “toastr” for notifications and “moment” for formatting, validating, parsing and manipulating dates [16], [18], [19].

Languages taken into consideration

As the first task, we investigated the code that was previously written for PEACH project and we detected that most of the components were heavily based on JavaScript technologies such as Node.js, React [1]. During the meetings that we held with the client and other teams we observed that most of the components in PEACH are going to make use of JavaScript for the front-end and for the back-end. However, since we were open to learn any languages and technologies for the PEACH project, the following languages were seriously considered for the back-end of the internal messaging system due to the reasons specified: JavaScript (Node.js – due to the unofficial requirements from the client and the previous code on GitLab), C# (due to Microsoft’s support to the project), Golang (due to its use in Mattermost platform mentioned below) PHP and Java (due to developers’ previous experiences) [1] - [7].

Final languages chosen

We decided to build our first prototype before finalising requirement gathering to have a better understanding of what the client wanted us to achieve and to try developing a Node.js app because of its heavy usage in the PEACH project and available frameworks and libraries such as Socket.io, Express.js and Meteor.js which are very convenient for building chat applications [1] - [4]. Another reason we decided on Node.js is that its event-driven and non-blocking I/O which makes Node.js very efficient and lightweight [2]. Also, Socket.io provides many functionalities for sending and receiving messages [4]. Our prototype was able to send and receive messages in real-time which solidified our opinions on Node.js as the technology of choice. After showing our prototype to our client, together we decided to use an open source chat platform to avoid re-inventing the wheel.

Strenghts of Rocket.chat

Rocket.Chat enables users to send direct messages and to send images and other files, to each other in real-time, to create private chat groups, to create users with different permissions, to star and pin messages and to view chat history. It also supports chatbot integration which will be useful for the future integration of the PEACH chatbot. Rocket.Chat also supports videochat in beta version so it will be fully available for users in the future.

Weaknesses of Rochet.chat

The first limitation of Rocket.Chat that we encountered Rocket.Chat’s codebase [17]. Rocket.Chat is a very comprehensive project with around 300 contributors and over 10000 commits on GitHub [17]. The project has 19 dependencies and makes heavy use of Meteor framework [17]. The same codebase includes test files, client i.e. front-end files, server i.e. back-end files and also many other libraries that were written by Rocket.Chat contributors [17]. Unfortunately, the documentation is very poor for developers who are going to start working on Rocket.Chat for the first time [16]. There are almost no comments in the code and there are no guidelines neither on Rocket.Chat’s official website nor on other websites such as GitHub or Stack Overflow which include information about Rocket.Chat [16], [17], [22], [23]. One of the very few ways to understand the function of a file or of a code piece is to use trial and error method i.e. changing something and observing the changes. Another way is to use browsers’ built-in debugging tools by using inspect code. The final way is to lookup a specific meteor or another library function or variable in their documentation to make sense of the code. Since this is a Node.js project built with Meteor every time we change the code we had to wait for a few seconds and usually a lot more depending on the change that we made for project to build again. Since the existing codebase were not logging almost any messages to the console this situation made it even harder for us to debug the app.

Final Solution

For deployment, we started to explore different servers on Azure. Since our client wanted us to use Azure only we did not have a chance to choose our cloud service provider. We decided to use the servers that we gained experience with during the first scenario week where we tried to deploy our app to AWS. Therefore, we decided to go with Ubuntu or Microsoft Server. We quite easily deployed the default version of Rocket.Chat by using “snaps”, a tool which makes deployment very easy, by getting the application from Rocket.Chat’s servers. However, another limitation of Rocket.Chat was the deployment of our customised app on Azure. Again, the documentation was very out of date and insufficient especially for Azure which they did not provide any guidelines for. After trying many online tutorials both in Rocket.Chat’s documentation and on other websites we started to think that we should switch to some other platform in order to have a deployable app. We had tried Empty NodeJS Web App on Azure, numerous Ubuntu versions such as Ubuntu 16.10, 12.04.5 LTS, Docker on Ubuntu and multiple Microsoft Servers [20]. After discussing this with the client, we started developing a simpler app using a much simpler open-source project which used Node.js and React since we did not have time to start over with Mattermost or Zulip [21]. While we were adding our features to the new chat platform, we kept trying to deploy Rocket.Chat on an Azure Ubuntu 16.04 LTS server. Finally, we managed to do so and got back to Rocket.Chat towards the end of the project.

References
[1] GitLab. ucl-peach, github.com. [Online]. Available: https://gitlab.com/groups/ucl-peach [Accessed: Apr. 10, 2017].
[2] Node.js. Node.js, nodejs.org. [Online]. Available: https://nodejs.org/en/ [Accessed: Apr. 10, 2017].
[3] Meteor. Developers, meteor.com. [Online]. Available: https://www.meteor.com/developers [Accessed: Apr. 17, 2017].
[4] Socket.io. Socket.io 1.0 is here, socket.io. [Online]. Available: https://socket.io/ [Accessed: Apr. 17, 2017].
[5] MongoDB. MongoDB Documentation, docs.mongodb.com. [Online]. Available: https://docs.mongodb.com/ [Accessed: Apr. 17, 2017].
[6] Rocket.Chat. Prepare to take off with the ultimate chat platform, rocket.chat. [Online]. Available: https://rocket.chat/ [Accessed: Apr. 15, 2017].
[7] Mattermost. Open source, private cloud Slack-alternative, about.mattermost.com. [Online]. Available: https://about.mattermost.com/ [Accessed: Apr. 15, 2017].
[8] Friends. P2P chat powered by the web, moose-team.github.io. [Online]. Available: http://moose-team.github.io/friends/ [Accessed: Apr. 15, 2017].
[9] Let’s Chat. Self-hosted chat for small teams, sdelements.github.io. [Online]. Available: https://sdelements.github.io/lets-chat/ [Accessed: Apr. 15, 2017].
[10] Zulip. Powerful open source group chat, zulip.org. [Online]. Available: https://www.zulip.org/ [Accessed: Apr. 15, 2017].
[11] Azendoo. Azendoo makes it simple to track teamwork, azendoo.com. [Online]. Available: https://www.azendoo.com/ [Accessed: Apr. 15, 2017].
[12] Bitrix24. Your company. United., bitrix24.com. [Online]. Available: https://www.bitrix24.com/ [Accessed: Apr. 15, 2017].
[13] Exo. Digital collaboration platform, exoplatform.com. [Online]. Available: https://www.exoplatform.com/ [Accessed: Apr. 15, 2017].
[14] Fleep. A messenger for all your teams and projects, fleep.io. [Online]. Available: https://fleep.io/home [Accessed: Apr. 15, 2017].
[15] HipChat. Great teams use HipChat, hipchat.com [Online]. Available: https://www.hipchat.com/ [Accessed: Apr. 15, 2017].
[16] Rocket.Chat. Rocket.Chat Docs, rocket.chat. [Online]. Available: https://rocket.chat/docs [Accessed: Apr. 15, 2017].
[17] GitHub. Rocket.Chat, github.com. [Online]. Available: https://github.com/RocketChat/Rocket.Chat [Accessed: Apr. 15, 2017].
[18] NPM. toastr, npmjs.com. [Online]. Available: https://www.npmjs.com/package/toastr [Accessed: Apr. 21, 2017].
[19] NPM. moment, npmjs.com. [Online]. Available: https://www.npmjs.com/package/moment [Accessed: Apr. 21, 2017].
[20] Microsoft. Global. Trusted. Hybrid., azure.microsoft.com. [Online]. Available: https://azure.microsoft.com/en-us/?b=17.14 [Accessed: Apr. 21, 2017].
[21] GitHub raineroviir/react-redux-socket.io-chat, github.com. [Online]. Available: https://github.com/raineroviir/react-redux-socketio-chat [Accessed: Apr. 22, 2017].
[22] H. Virdo. (2016, Mar 7). How to install, configure, and deploy Rocket.Chat on Ubuntu 14.04. Digital Ocean [Online]. Available: https://www.digitalocean.com/community/tutorials/how-to-install-configure-and-deploy-rocket-chat-on-ubuntu-14-04#step-4-—-configuring-rocketchat-as-a-service [Accessed: Apr. 22, 2017].
[23] StackOverflow. Highest voted Rocket.Chat questions, stackoverflow.com. [Online].Available: http://stackoverflow.com/questions/tagged/rocket.chat [Accessed: Apr. 22, 2017].

As the main functionality of the app should consist of allowing multiple persons to contribute on the same note component in real time, initially the research has focused on choosing the right technology to build the collaborative editing tool.

Frameworks/platforms taken into consideration

First of all, we have considered the resources provided by our client [1]. After reading about various solutions such as ownCloud Documents [2], Gooby [3], Etherpad [4], Only Office [5] and Firepad [6], we have decided to implement each of them in order to check their functionalities and spot the differences. Moreover, we have searched for other “Google Docs” alternatives, as the concept could be approximately the same. This way, we have explored Dropbox Paper, Zoho Writer or Quip [7], but none of them represented an option for our component.

Some other collaborative text editor tools considered were Meeting Words and collabedit. However, they have been dismissed as possible solutions for our project since the “must have” and “should have” requirements would have not been met by their implementation.

As it is presented in our experiments log (link), we have taken into account all their functionalities. However, when it came to make the final decision, we have used the MoSCoW analysis in order to see which is the most suitable solution for our project. In the end, the two main options that we have considered were Etherpad and Firepad. However, Firepad offered more advantages than Etherpad, by not requiring a server-side code, since it uses Firebase as backend [6]. Firepad also allows adding pictures in the the text, presenting a richer formatting function. After deciding on the Firepad technology, we have started to read more about the Firebase backend and to implement a several prototype components.

Strengths and weaknesses

A more detailed and in-depth analysis of the strengths and weaknesses of the tested frameworks can be seen in the Experiments page of our website, where we have detailed and compared each one of the options.

Final Solution

At the beginning of Term 2, we have discussed with my client about our chosen technology and we have agreed to switch from the Firepad technology to the Etherpad one, since we were not allowed to use a Firebase backend due to patient-data related reasons. Therefore, Etherpad has been the final technology used for our Collaborative Document Editing Tool, as it was meeting all the requirements for our project. Moreover, the reason of choosing Firepad over Etherpad was mainly the Firebase backend, which in the end we were forbiden to use due to the confidenciality agreements of data patient.

Summary of Final Decision

At the end of my research, we have concluded that the best two options were represented by Firepad and Etherpad. As our client first recommended us, we chose Firepad, because it seemed to be an easier approach for our project. However, after carrying out a more in-depth research on the Firepad technology, we realised that the implementation of this framework wouldn’t have been appropriate for our project as our client informed us about using the patient data on a different server. Therefore, we agreed to adopt Etherpad as a final solution for our project, decision which has been successfully implemented.

References
[1] Kochedykova T. 5 open source alternatives to Google Docs Available on: https://opensource.com/business/15/7/five-open-source-alternatives-google-docs [Accessed 15th October 2016]
[2] Own Cloud. Home. Available from: https://owncloud.org/features/ [Accessed 15th October 2016]
[3] Gobby. Home. Available from: https://gobby.github.io [Accessed 15th October 2016]
[4] Etherpad. Home. Available from: http://etherpad.org [Accessed 15th October 2016]
[5] Only Office. Home Available from: http://onlyoffice.org [Accessed 15th October 2016]
[6] Firepad. Home Available from: https://firepad.io/ [Accessed 15th October 2016]
[7] Brandon J. 5 good alternatives to Google Docs Available from: http://www.techradar.com/news/software/business-software/5-good-alternatives-to-google-docs-1320684 [Accessed 20th October 2016]