{'fraction_non_alphanumeric': 0.022475277195085405, 'fraction_numerical': 0.001997802417340925, 'mean_word_length': 4.963073257891602, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
CERN AppStore: Development of a multi-platform application management system for BYOD devices at CERN

The number of BYOD continuously grows at CERN. Additionally, it is desirable to move from a centrally managed model to a distributed model where users are responsible for their own devices. Following this strategy, the new tools have to be provided to distribute and in case of licensed software also track applications used by CERN users. The available open source and commercial solutions were analyzed and none of them proved to be a good fit for CERN use cases. Therefore, it was decided to develop a system that could integrate various open source solutions and provide desired functionality for multiple platforms, both mobile and desktop. This paper presents the architecture and design decisions made to achieve a platform-independent, modern, maintainable and extensible system for software distribution at CERN.


Introduction
A tool called Computer Management Framework (CMF) is used to manage computers at CERN. This tool was developed at CERN and is installed on every Windows device joined to the CERN domain. It allows two types of management approaches. Centrally managed computers where the schedule for application, updates, and patches are decided by the IT department and locally managed computers where a group of delegated administrators decides about which applications or patches should be installed on a defined set of computers and when it should happen. All of the managed devices must be a member of the CERN domain. The world is rapidly changing and also the expectations of the users at CERN. The Bring Your Own Device (BYOD) model has become very popular where people are being allowed to use one's personally owned device, rather than being required to use an officially provided device by the organization. Nowadays people own powerful and efficient devices, which, in most cases, are already part of their daily work routine. These devices are not part of the current management model, therefore they have no access to the CERN provided and licensed software.
To meet people's expectations CERN aims to extend the current offerings and providing a platform where recommended and required applications will be provided to all the personnel's devices regardless of them being a part of a CERN domain or not.

Management model
Our new management model shifts the focus from managing devices to managing applications, as it is presented on Figure 1. In this way we are able to offer application support either to CERN owned or BYOD devices. To achieve this goal, we needed a new tool, which is able to provide applications without central management dependencies, like active directory membership, access to intranet or file shares.
As the list of supported (and planned to be supported) platforms became wider, we aimed for a system which is platform independent and can be made available on mobile and desktop environments as well. The designed tool strictly implements application management only. It does not manage the clients, push system updates or force any corporate policies.
Our goal was to build the system in a way to profit from already existing and widely used distribution tools. The provisioned applications come from different sources, which vary by platforms, as it can be a platform specific application store, an installer or a package for a platform specific package manager. The following section presents the selected technologies to implement the system.

System architecture
The system consists of multiple Docker [1] containerised components, which are automatically built by GitLab's continuous integration pipeline. Figure 2 presents the architecture of the system. The docker images of the front-ends and back-end are deployed to the Red Hat OpenShift container platform [2], while the MongoDB [3] database is running also as a Docker container but on a dedicated virtual machine in the CERN Cloud Infrastructure [4]. Every component is integrated with CERN's Authentication and Authorization system, which is a Keycloak [5] based solution.

Front-end
The user interface (UI) of the system is designed to be responsive. It supports smartphones, tablets and desktop clients. The React [6] library was used to implement the user interface, as it is an industry-standard and widely used open-source solution to build user interfaces. React is also widely used in the CERN IT department which allows providing required support and maintenance. Redux [7] is used as a global state management module. The user-facing components are built with Material-UI [8].

Back-end
We needed a back-end technology that is platform-independent, flexible and easily extensible. We decided to use Node.js [9] and Express to serve the REST API as it satisfied our requirements and made it possible to implement the back-end and front-ends with the usage of a homogeneous technology stack. The back-end is using a middleware based software architecture. The chained middlewares are responsible to filter out unauthorised requests (Keycloak middleware), check the received input, get requested data from the database, persist data into the database, and assemble the response to the clients.
The system used MongoDB as a data persistence layer during the development and pilot phase because it helped us in fast prototyping. MongoDB is a NoSQL database engine without strict data schema and it is able to store and return JavaScript objects as JSON documents, therefore the integration and usage in Node.js environment is straightforward. Regardless of MongoDB worked reliable during the pilot, the final system will use PostgreSQL [10]. Post-greSQL is officially supported by CERN's database team and it supports user-defined data types above the standard SQL data-types. In this way, PostgreSQL offers the same flexibility with these JSON typed fields as the NoSQL database engine did, but with all the advantages of the regular relational databases.

Desktop client architecture
The desktop client was designed to have the same look and feel on any platform. However, each platform has specific component requirements like package manager or libraries, therefore the client application consists of two separate layers, a platform-independent user interface, and a platform-specific package manager layer.
The user interface of the client is based on the same React UI as the web interface and it is packaged into an Electron [11] application. In this way, it has the same look-and-feel and code base as the web interface.
To manage applications the client needs a platform-specific layer. On the Windows operating system, this platform-specific layer is implemented in .NET C# and it is using Chocolatey [12] as a package manager. This layer has full access to the Windows API.
The communication between the two layers has to be implemented on a platformindependent way. We decided to use a RESTful communication interface between the Electron user interface and the package manager layer. The user can send commands from the React view through inter-process communication (IPC) to the Electron process to access OS level operations, or through RESTful requests directly to the package manager layer. It is a flexible solution where new platforms can be easily added to the system by implementing the platform-specific package manager layer of the new platform.

Supported platforms
The system was designed to support mobile and desktop-like devices and to be easily extendable to the emerging platforms in the future. The current system supports Android and iOS mobile devices including Android and web applications for Chromebooks and has a dedicated desktop client for Windows operating system. Besides native applications, the CERN AppStore provides also links to web applications, for example, CERNBox [13] and MapCERN. This allows us to provide in one place all types of applications that can be useful for our users.

Application types
The behavior of the system differs based on the application type. It can be: • Redirection to a web URL • Redirection to a platform-dependent application store • Download an application installer (e.g. apk, exe) • Install a package with platformdependent package manager.
The users can benefit from the support of the communities and official application stores as well as from the offered and licensed software from CERN's own application repository.

Categories and roles
The applications will be presented to the user by category. One application can be added to multiple categories. Access to a category can be restricted based on user roles. In this way, only a subset of the users will have access to a restricted category. Roles are assigned to users  Keycloak) and will be included in the user's token after login. The system's back-end uses these roles to filter the application categories offered to a user.

Usage statistics
Collecting some basic usage data is necessary to analyse and understand the application usage and adjust the offered application's list to the user's needs. The system collects usage statistics from the clients and web users, like application page visits, installations, and application usage from native clients. Figure 4 presents an example view from the statistics calculated from the collected usage statistics.

Conclusion
The main challenge of the project was to design and build a system, which can operate on multiple platforms, both in mobile and desktop environments, offers applications from mul-tiple application sources and eliminates all the organisation specific dependencies of the current central management framework. The system architecture is designed to be modular and containerised and the clients to be easily adaptable to new platforms.
The realised solution satisfies these requirements. It uses modern open source technologies and industry-standard solutions while it profits from already existing tools and the support of external and internal software providers.