# PALANTIR: An NFV-Based Security-as-a-Service Approach for Automating Threat Mitigation
## 6 Validation
### Qualitative Evaluation
#### 6.2.6 Security Portal Prototype Implementation  
The prototype Portal is composed of a front-end and a back-end component. The front-end is simply the implementation of the web application, while the back-end is responsible for functionalities such as user management, storage of historical data, notification ingestion, and coordination of communication with the rest of the PALANTIR components.  
The front-end is a React.js application, and is designed following the guidelines of Material UI. It is meant to be a fast and lightweight application that any user can access through their browser. The front-end is served via a node.js server. The serving of this application, i.e., the node server, is coupled with the portal back-end, which encloses the node.js server for the web application in its environment. The front-end connects to the PALANTIR platform by authenticating through the user authentication endpoint of the back-end REST API. Data access is achieved via calling the back-end REST API with Axios, and live notifications are sent to the front-end via a Web Socket connection using Socket.io. The REST API exposed by the back-end is segregated based on the different concerns, mainly viewing data points or datasets, as well as some basic management options.  
The back-end is implemented as a small collection of services, organised around a service implemented in Java 11 using Quarkus 2.15 framework. Quarkus was selected as it is easily extensible, uses best-of-breed patterns, technologies, and standards, and is lightweight. The Quarkus flavor used is the reactive one, with reactive data types provided by Mutiny used wherever necessary, while in other cases methods are annotated as transactional. The data storage for the back-end is achieved using a PostgreSQL 15.1 database. Connectivity with the database is achieved with the standard Quarkus extensions, using JDBC and Hibernate ORM for PostgreSQL.  
All notifications and events meant to be viewed by the user reach the portal via a Kafka message bus. In order to facilitate connection with the PALANTIR data and event streams in Kafka, the back-end uses the Kafka connector that is based on the Smallryereactive messaging. The back-end connects to the different Kafka topics that the platform is supposed to use, and has consumer handlers that use the methods of the message classifier service. The messages are processed in order to be stored, or further processed before storage, and are also sent to the connected users via the open Web Socket connections. This real-time alerting is completed with the Quarkus Web Sockets extension, so that an alert socket is created when a new client connects to it.  
KeyCloak is used for user Identity and Access Management (IAM) as an external service, and it is connected to the back-end with the Quarkus KeyCloak Admin Client, the usage of which is wrapped in custom service implementations. The key user data are kept in KeyCloak, while further data regarding client organisations and their users, such as the past incidents and applied remediations, are kept in the PostgreSQL database mentioned earlier.