SFTSDH: Applying Spring Security Framework With TSD-Based OAuth2 to Protect Microservice Architecture APIs

The Internet of Medical Things (IoMT) combines medical devices and applications that use network technologies to connect healthcare information systems (HIS). IoMT is reforming the medical industry by adopting information and communication technologies (ICTs). Identity verification, secure collection, and exchange of medical data are essential in health applications. In this study, we implemented a hybrid security solution to secure the collection and management of personal health data using Spring Framework (SF), Services for Sensitive Data (TSD) as a service platform, and Hyper-Text-Transfer-Protocol (HTTP (H)) security methods. The adopted solution (SFTSDH = SF + TSD + H) instigated the following security features: identity brokering, OAuth2, multifactor authentication, and access control to protect the Microservices Architecture Application Programming Interfaces (APIs), following the General Data Protection Regulation (GDPR). Moreover, we extended the adopted security solution to develop a digital infrastructure to facilitate the research and innovation work in the electronic health (eHealth) section, focusing on solution validation with theoretical evaluation and experimental testing. We used a web engineering security methodology to achieve and explain the adopted security solution. As a case study, we designed and implemented electronic coaching (eCoaching) prototype system and deployed the same in the developed infrastructure to securely record and share personal health data. Furthermore, we compared the test results with related studies qualitatively for the efficient evaluation of the implemented security solution. The SFTSDH implementation and configuration in the prototype system have effectively secured the eCoach APIs from an attack in all the considered scenarios. The eCoach prototype with the SFTSDH solution effectively sustained a load of (≈) 1000 concurrent users in the developed digital health infrastructure. In addition, we performed a qualitative comparison among the following security solutions: SF security, third-party security, and SFTSDH, where SFTSDH showed a promising outcome.


I. INTRODUCTION
IoMT has been an emerging ecosystem of wireless and connected medical-grade devices. It provides exciting opportunities in the healthcare sector to collect, transfer, and store personal health data over a network without necessitating human-to-human or human-to-computer interaction [1], [2]. IoMT is a combination of Internet-connected medical devices (including wearable devices and standalone devices for remote patient monitoring) and patient The associate editor coordinating the review of this manuscript and approving it for publication was Mansoor Ahmed .
information [3]- [6]. The connectivity between medical devices simplifies clinical workflow management and improves patient care in medical institutions and remote areas [5]- [8]. In the IoMT ecosystem, IoMT devices collect or perceive data and information about health and personal well-being and then send them to databases or other IoMT devices or clouds or nodes (for example, fog or edge computing nodes) over the Internet [7]- [11].
The lack of security awareness may promote the following attacks on the IoMT ecosystem: illegal penetration attempts (e.g., cross-site forgery (CSRF), cross-site scripting (XSS), cross-source resource sharing (CORS) and Clickjacking), asset destruction, record theft, denial of service (DoS), distribution DoS (DDoS), man-in-the-middle attack (MITM), content sniffing (CS), brute force attack (BF), Internet protocol (IP) spoofing and therapeutic manipulation (TM) [5]- [7]. The Open Web Application Security Project (OWASP) discovered that IoMT security vulnerabilities include the following [5]- [7]: • Inadequate authentication and authorization, • Exposed Application Programming Interfaces or APIs (e.g., mobile, web, cloud), • Inefficient data transmission encryption, • Vulnerable network services, • Privacy issues, and • Deficient security configurability Therefore, guaranteeing the safety of IoMT is an acute problem to be resolved. Due to the rapid growth of IoMT solutions and the continuous development of IoMT technology, security assurance has caused issues for IoMT users and organizations adopting IoMT technology. These problems exist, especially when choosing appropriate and reliable safety measures for the situation. Thus, authorized, and authenticated users or devices should only access the IoMT healthcare system. Insufficient authentication may cause an attacker to enter the system and access the user's private healthcare data. More and more malicious attackers target medical servers and digital medical systems because personal medical data and information are precious in the illegal market [3], [5]- [7]. Therefore, medical service providers require even more robust security measures, which inevitably increase the cost of creating, operating, and maintaining these medical services. Due to security breaches, retrieving and eliminating stolen data is both challenging and critical. The government and medical institutions must formulate strict regulations and severe penalties to protect patients' health records.
The reliability and credibility of eHealth scientific research and associated services rely on the health data protection plans and guidelines regarding security, privacy, and confidentiality. The Health Insurance Portability and Accountability Act of 1996 (HIPAA or the Kennedy-Kassebaum Act) of the United States (USA) [12] and the EU GDPR [13] are two worldwide accepted standards (or Privacy Rule) for the protection of individually identifiable health information. The principles of the privacy law cover the use and disclosure of health information from individuals -called ''protected health information''. The primary purpose of the privacy policy is to ensure that individuals' health information is adequately protected while facilitating the flow of health information required to provide and promote high-quality health care and protect the health and well-being of the public. Personal data is the information that can identify a person, directly or indirectly [12]- [14]. It primarily includes online identifiers such as IP addresses, cookies, digital fingerprinting, and location information that may identify people [12]- [14]. The GDPR [13] has the following six general data security standards: • Fairness and lawfulness • Limitation of purpose • Minimization of data • Precision • Limitation of storage • Honesty and confidentiality Norwegian data protection policies (NORMEN) [14], another Norwegian health and care provider standard for information protection and privacy, is an agreed collection of information security standards based on legislation. In the modern digital data era, it is no longer possible to run research on sensitive data on local facilities, with limited capacities and no possibility to share results with collaborators. Research environments at universities and university hospitals have expressed a need for ample storage space for sensitive research data to handle.
This research aims to develop a secure digital health infrastructure with SFTSDH security solution for research and innovation services, providing secure hosting and operation of application services, collection, storage, processing, and provisioning of data, and test the security solution with the deployment of an eCoach prototype system as a case study. We adopted Representational State Transfer (REST)-based microservices architecture (MSA) with Spring Framework to develop lightweight eCoach APIs with independently deployable services to increase granularity and agility. Limited studies focused on applying security solutions at the MSA level, which has been addressed in this research. The different gaps between this study and the existing studies have been captured in Section III. This research addresses the following research questions -1. How to protect REST APIs from external vulnerabilities with an integrated security solution approach (SFTSDH)?
2. How to extend the SFTSDH with VPN, Bcrypt hash, API key, network firewall, and SSL protocol to build a digital health infrastructure?
3. How scalable and effective is the adopted security solution approach?
SFTSDH implements security features, such as identity brokering, OAuth2, multi-factor authentication, CORS, and user management to protect the REST APIs from illegitimate access and external attacks, such as CSRF, XSS, Clickjacking, content sniffing, and brute force. An eCoach prototype system has been deployed in the developed digital health infrastructure to conduct a formal security analysis of the integrated security solution scheme as a case study. In addition, performance analysis and qualitative analysis have been performed to show how scalable and effective is the adopted security solution approach.
The rest of this paper is designed as follows. Section II describes the essential preliminaries required for the adopted security solution. Section III describes related work and emphasizes the difference between existing and our work, focusing on the architectural aspects besides different security features. In Section IV, we present our developed digital health system architecture.
Section V describes the adopted security solution. In Section VI, we describe experimental results. The paper is concluded in Section VII.

II. ESSENTIAL PRELIMINARIES
The needed technical background to realize the SFTSDH security solution has been described in this Section. In healthcare systems (e.g., eCoach [18]- [21]), personal health data are collected from various sources (e.g., wearables, fitness trackers, medical devices, assessment tools, self-reports, and user applications). According to the GDPR and Norwegian law, personal research data and information are sensitive and must be stored and processed under strict regulations [13], [14]. There are different security methods described in Section III to protect REST APIs. However, in combination with SF [15] and TSD platform [16], the HTTP security paradigm [17] may offer a parallel approach to prevail security functionalities, their features, session management, secure communication, and access management solutions for REST APIs. The reasons behind adopting SF, TSD platform, and HTTP security paradigm in our security solution are: (a.) Spring Framework [15], [22] provides a comprehensive programming and configuration model for modern Javabased enterprise applications on any deployment platform.
A key element of Spring is application-level infrastructure support. Spring focuses on the ''pipeline'' of enterprise applications so that developers can focus on application-level business logic without unnecessary contact with a specific deployment environment.
(b.) TSD (service for sensitive data) [16] is a GDPR supported platform for collecting, examining, and offering sensitive information consistent with the NORMEN. The TSD is an IT platform for research, regardless of whether it is sometimes utilized for clinical exploration and business research. TSD has been created and worked by the University of Oslo (UiO) and is a piece of NorStore, the public foundation for dealing with logical information. All the services and data are protected inside of TSD from illegitimate access. The TSD offers services such as client registration (signup, confirmation, getting an API key, and password reset), authentication and authorization with access tokens, file import and export in JavaScript Object Notation (JSON) (simple file upload and download, resumable file upload and download, resuming uploads and download, four different types of access tokens for both basic authorization and TSD authorization services (survey_import, survey_export, survey_admin, and survey_member), queries for filtering, encryption (Base64 encoded) of JSON and file data. In this research, TSD has been considered a third-party Identity and Access Management (IAM) platform.
(c.) HTTP [17], [23] is a ubiquitous protocol and one of the foundations of the network. HTTP is a stateless protocol based on messages (requests, responses), headers (key-value pairs), and optional bodies. The HTTP protocol works on the Transmission Control Protocol (TCP) [23]. TCP is one of the core protocols in the Internet protocol stack. It provides reliable, orderly, and error-checking data stream transmission, making it an ideal choice for HTTP [23]. Some essential features of HTTP in a web security context are [17], [23]: query string, URL encoding, cookies, built-in authentication mechanism (e.g., Basic and Digest), and Headers. Basic and Digest are two built-in methods of HTTP. However, other authentication methods are Windows NT LAN Manager (NTLM), IWA (Integrated Windows Authentication or Kerberos), Transport Layer Security (TLS), or Secure Socket Layer (SSL) client certificates. In addition, forms authentication, OAuth2, Security Assertion Markup Language (SAML), JWT (JSON Web Token), and many other types of authentication options reuse features in HTTP (such as form data or headers) to authenticate the client [23]. HTTP headers are used to pass additional information in requests and responses. Usually, custom headers start with X-(for example, X-Content-Type-Options header, X-Frame-Options header, etc.), but this is just a widely adopted convention, not by the HTTP protocol [23].
The MSA [24] helped to avoid the following drawbacks associated with traditional monolithic approaches to software development [25], [26]: bundled deployment as a single stack, limited scalability, DevOps challenges, and high resource cost. Subsequently, we deployed the eCoach prototype in the intended secure digital infrastructure and performed functional testing for acceptability. REST endpoint security includes the following methods: HTTP-based authentication scheme with basic or bearer token, API keys, OAuth2 with the access token and refresh token, and OpenID Connect (e.g., OpenID, BankID). OpenID Connect (OIDC) [27] is a thin layer on top of OAuth2 that adds insights concerning the client signing into the client profile. TSD supports the following four types of authentication schemes: basic, two-factor, ID-porten, and dataporten. We used TSD's twofactor authentication scheme and access token-based authorization method for REST API security. eHealth scientific research and related services' reliability and believability depend on the health data security plans and rules regarding security, and confidentiality. For this research, we got an ethical endorsement from The Norwegian Center for Research Data (NSD) and Regional Ethical Committee (REK) for overseeing information for our eHealth research in Norway.

III. RELATED WORK A. eHEALTH SECURITY AND PRIVACY REQUIREMENTS
Articles associated with eHealth research reveal the subsequent security and privacy requirements in healthcare systems for both on-premises and cloud-based [28], [29]: EHR security, user authentication, governing amenability, authorized access, secrecy, ethical consent, legal issues, the relevance of data access, data ownership, data uniformity, data separation, security audits, archiving, requirements for third-party certificates (such as SAS70 Type II, PCI DSS Level 1, ISO 27001, and FISMA), protection against external security threats (such as DoS, DDoS, MITM, IP spoofing), security policies, security protocols, and database access management. The identified vital security terms can be disseminated in the following four categories: authentication (multi-factor, formbased, access token, and API key), authorization (OAuth2, OpenID, Dataporten, and CORS), encryption (digital certificate, SSL, RSA, Bcrypt, SHA-256, Base64, and MD5) and external security threats (CSRF, DDoS, MITM, XSS, brute force, and IP spoofing). Authentication is used to verify personal identity; identity verification is related to verifying credentials. The plan determines whether the person is a legitimate user. Authorization is a mechanism used to determine whether a particular service is available to authenticated users. It verifies that users have the right to personally access resources such as records, databases, and files. Usually, authorization is performed after authentication to verify the user privileges. Encryption uses an algorithm to encrypt, encrypt data and then use a key to decrypt, which is the information of the receiving group. External threats are the possibility that people outside the system may use malicious software, hacking, disruption, or social engineering to exploit system vulnerabilities. Healthcare research shows various studies [24], [30]- [39] associated with security and protection in electronic health records (EHRs), secure health monitoring framework, security conventions, and endorsement plans, security contemplations in medical services applications, strategies for medical services security, and interoperability, healthcare cloud, big data security, medical services security consistence, security execution, security difficulties, and success factors. However, studies related to security solutions at the Microservice Solution Architecture Level (MSSA) are limited.

B. MSSA
Salibindla [40] surveyed MSSA and Microservice API security methods (e.g., OAuth, HTTPS), focusing on the security of communication protocols. A security architecture [54]- [59] consists of security principles, methods, and models designed to align with business goals and help protect organizations from cyber threats. The key attributes of a secure web application architecture are [54]- [59]: Inter-tier VOLUME 10, 2022 authentication (e.g., LDAP, Kerberos, Mutual SSL, IP Validation, ID Portal), Server-side validation (e.g., secure Proxy, protection against external attacks), Secure communication (e.g., HTTPS), data encryption and logging. The microservice open security architecture framework provides a comprehensive overview of the vital security issues, principles, components, and concepts that are the basis for the architectural decision-making involved in designing an effective security architecture. Xie et al. [41] published a result on Spring API Security architecture and implementation without verifying the effectiveness of the Spring Security Framework (SSF) and OAuth2 when these technologies were used to enforce Microservice API endpoint authentication and authorization. Nguyen et al. [25] conducted a proof of concept (PoC) of a Microservice application using SSF and OAuth2 to reduce the knowledge gap on Microservice and API security. However, they did not test how the solution would work after integrating with a third-party IAM platform. Dikanski et al. [26] completed a conceptual study to identify and execute authentication and authorization patterns in the SSF to reduce the gap between the design and implementation of pattern-based protection to include high-quality security characteristics in software systems. Nevertheless, their study suffered from the SSF's actual performance to protect Microservice at the API endpoint level with integration with IAM platform. Alofi et al. [42] proposed a secure and cost-effective model based on the Message Queuing Telemetry Transmission (MQTT) protocol to protect IoT resources through access control to RESTful Web services. Beer et al. [43] proposed an adaptive security architecture based on neural networks to protect RESTful Web services in enterprise computing environments through three functional principles-intelligent methods for predicting, preventing, and learning to detect future threats. The core of their security solution is to protect HTTP transactions based on Public Key Infrastructure (PKI) and related encryption technologies. The interpretation results show that compared with the supported network/transport layer security, the proposed security solution is suitable for protecting REST and is better than SOAP-based Web services. Since RESTful Web services are stateless, they usually do not have any session to perform the challenge-response mechanism. TLS/SSL provides secure peer authentication.
Nevertheless, when the authentication request is based on delegation, this mechanism is not sufficient to allow the site to authenticate on behalf of its users. HTTP security (HTTPS) is widely used confidentiality, but it only provides hop-by-hop protection. An excellent RESTful solution follows a tokenbased approach. Serme et al. [44] proposed a security model based on confidentiality and digital signatures to protect RESTful messages. These messages carry undeniable tokens and provide data secretly by encrypting their contents. They proposed a protocol to ensure the communication security of RESTful services. They provide encryption, signatures, and their combination. They do not intend to offer an equivalent secure session for RESTful services because it is related to the transport layer security of HTTP, which has been resolved in protocols such as SSL and TLS. Backere et al. [45] Designed a security solution for RESTful Web services using non-RESTful elements to outperform TLS.
The summary of the security solutions concerning essential attributes of a secure web application architecture and security features are described in Table 1 and Table 2 and are further compared with our adopted SFTSDH security approach. Table 1 and Table 2 show how our SFTSDH solution is different from the existing studies.

C. STATE-OF-THE-ART
This study aims to reduce the MSA and API security knowledge gap and protect REST APIs by creating an MSA application prototype using SFTSDH (see Table 2). In conjunction with Spring Framework, TSD platform, and HTTP methods, we implemented a parallel API protection solution (SFTSDH) with pre-existing security features such as identity brokering, OAuth2, multi-factor authentication, and CORS. We performed unit testing to validate the security solution at the modular level. Moreover, we created a self-signed SSL certificate with Keytool to protect sensitive information on the web using public key (RSA) encryption [46]. On top of the SSL protocol, we used ''eduVPN'' to provide a safer E-2-E connection with service encryption and changed IP addresses. It did not only help data traffic to pass all the mid-points safely but also provided access control by allowing legitimate VPN users to access the REST endpoints of the eCoach prototype system. Finally, we validated the scalability of the adopted approach as a performance metric. In our solution approach, all the implemented security features are described in Table 3.

IV. SYSTEM MODELING
Personal health and wellness data are usually collected over time through wearable sensors, offline and online interactions, smartphone apps, self-reporting questionnaires, and feedback forms [18]- [21]. To collect contextual weather data over time, both free and paid weather APIs and various weather sensors are available in the AppStore or marketplace. For ubiquitous tracking and distinct levels of physical activity measures, high-end, time-dependent activity data collection with wearable BLE-enabled devices has become known and achievable. Wearable activity sensors are connected via Bluetooth communication technology (BLE) to a smartphone. The eCoach smartphone application can seamlessly track and transfer high-resolution raw acceleration data to safe storage for further processing with a scheduler module. Some activity data are questionnaire-dependent (self-reporting), such as non-wear time and intense activity information. Physiological data can be collected (e.g., weight, blood pressure, heart rate, SPO2, body assessment data) either invasively (e.g., glucose level, lipid profile) or non-invasively. Based on the self-reported questionnaire, behavior data (dietary and habit) are collected either regularly or irregularly (alternating days or weekly). Baseline data (demographic data, medical history, personal preferences, initial weight and height, initial blood pressure, initial lipid profile, initial glycemic response, and initial body assessment data) are being collected for demographic statistics or population clustering, or individual target assessment during the participant's initial recruitment or monthly basis.
In this context, we have developed a digital health infrastructure after extending the SFTSDH features with VPN, Bcrypt hash, API key, firewall, and SSL as depicted in Figure 1. Moreover, we deployed a health eCoach prototype system in the developed infrastructure to execute a formal security testing of the adopted SFTSDH solution and it is depicted in Figure 2 and Figure 3 for a smartphone application (app.) version and a web version, respectively. We maintained a modular structure for our eCoach prototype system with the following modules [21]: activity (for device provision, collection and visualization of activity intensity, activity pattern, activity classification, posture detection, and step count over time), scheduler (for periodic notification generation and activity data transfer), eCoachUI (user interface for forms, dashboard, and basic information), eCoachBusiness (for the management of user login, complaint, performance, and data), weather (for the collection of weather data from OpenWeather using API-Key authentication and visualization of weather trends), and fhir (for data interoperability with HL7 protocol and medical ontology [47]). FHIR stands for Fast Healthcare Interoperability Resources for providing semantic and structural interoperability in personal and person generated health data with FHIR resources and clinical vocabularies.
A project p-1075 was created on 11th March 2020 under the name ''diferi'' on behalf of UiA on TSD side. The TSD infrastructure (see Figure 1) was established to support researchers, digital service operators, healthcare service providers, and third-party system and solution vendors to carry out research and innovation work jointly with the Centre for e-Health at UiA, the Centre for eHealth Research I4Helse, and other research groups, partners, and customers. The TSD infrastructure collects, stores, and exchanges different health-related data. It supports incoming data generated from the following dissimilar sources: • UiA Private Network or Secured Research and Innovation Infrastructure that collects data from sensors, questionnaire, usability lab and the living lab (Boligsimulator) and project terminals.
• Research participants or Public Communication Infrastructure that collects data from wearable sensors, non-wearable sensors, and questionnaire.
• Research and Innovation Partners or External Infrastructure that collects data from sensors, questionnaire, and project terminals.
TSD infrastructure supports project specific servlets (PSS), data storage, and inbuilt servlets. TSD infrastructure can host multiple services in respective VMware. All the collected data are sent to specific services (e.g., eCoach) deployed in the TSD virtual machines (VMware) using HTTPS, following the TSD authentication and authorization rules, and further stored in the central TSD database. TSD infrastructure additionally supports standard-based EHR or patient-journalsystem (PJS), secure access to the data for project-specific services (e.g., for processing and evaluation of the data for decision-support services), and the secure provisioning of the data to facilitate smooth exchange and interoperability  between infrastructure components and project partners. The project aims at the following outcomes: • Components in the digital health infrastructure for secure collection and storing of health data.
• Establishment of a pilot service for project-specific data collection and processing.
• The environment to store Audio & Video (A/V) recordings securely.
• Providing seamless, secure, and full access for UiA users and external partners to the digital infrastructure. Following a general decision by UiA/IT, the TSD infrastructure within this pilot project will be established within the TSD platform at the University of Oslo. In line with this, an EHR or PJS for standard-compliant reception and provisioning of health data has been set up within TSD. A secure communication mechanism and access control have been established between the TSD proxy gateway and the EHR/PJ server. As a pilot study to test the established infrastructure with a project-specific prototype service for research, eCoach services have been deployed and integrated into the secure digital infrastructure. That pilot services receive project-specific person-generated data (PGDs) from external user devices and applications and store the data in the TSD database following semantic and structural interoperability. The pilot services boost project-specific data processing, decision support, real-time communication with user devices The Usability Lab and the Living Lab (Boligsimulator) of the I4Helse environment at UiA support the audio-visual observation, monitoring and recording of test scenarios for research and innovation purposes. Audio-Visual recordings from human test participants must be treated as personal, privacy-relevant data, and must be handled securely. For this, the secure digital infrastructure within the TSD system will be connected to the audio/video lab facilities at UiA/I4Helse, to allow secure transmission, storage, analysis, and access to the recorded content. Shared data access requires strong security and access control. At the same time, established access control solutions at UiA and external partner institutions, such as Feide, BankID will be supported. These access control mechanisms will be integrated with the access control solution of the TSD system to extend the robustness of the solution. In this study, we have focused on project aims (a) and (b). The remaining project aims (c) and (d) are of the future research focus.
TSD does not allow outgoing API calls inside the projects and is open for the registered networks only. TSD's internal IP addresses are not published to external DNS services. Therefore, we set up a project-specific proxy at UiA. Each service deployed inside the TSD infrastructure is accessible from outside TSD with exposed REST-APIs using OAuth2. TSD can provide an infrastructure to host multiple disjoint projects and connect services to a secure, centralized database server. TSD PostgreSQL database is protected by its access control list (ACL) rules and authentication mechanism. Further details related to the service deployment inside TSD as a docker image and its access outside TSD using the necessary security tokens are discussed in Section V.

A. DATA COLLECTION
The activity module is responsible for activity device registration, device allocation, seamless collection of sensor observations, and sending it back to the eCoach business module for storing data in a PostgreSQL database. We used a wearable MOX-2 [48] activity monitor to collect personal activity data for the following measurement parameters -physical activity classification (low intensity, medium intensity, and high intensity), posture detection (sedentary, standing, and weightbearing), physical activity intensity (counts per minutes), and steps. It is an activity monitor based on a BLE accelerometer embedded. Consuming low power, the device can seamlessly measure and transmit high-resolution raw acceleration data and multiple activity parameters per second for seven consecutive days (up to 60 days). Activity data collection is a twostep process: a. activity data collection from MOX-2 activity sensor to personal mobile in CSV format using BLE protocol, and b. periodic uploading of CSV data from mobile location to activity module for persistent storage and further analysis using a scheduler service using HTTP-POST (see Figure 4). The weather module periodically contains weather updates from OpenWeather REST APIs (latest and hourly) with API-Key authentication and sends them back to eCoach business logic for stable storage. The questionnaire module consists of six question sets -daily, alternative day, weekly, interview, baseline (monthly), and feedback form. The participant submits the questionnaire, which is stored back in the database through eCoach business logic.

B. eCOACH SYSTEM (APP. VERSION VS WEB VERSION)
The eCoach endpoints are exposed as REST APIs. All the modules are connected to a PostgreSQL relational database system for persistent data storage using object-relational mapping (ORM) via the HAPI-FHIR module for semantic representation of PGDs using medical terminologies in JSON. The activity, scheduler, and eCoachUI modules are written using a Spring-Framework, and their exposed REST APIs are tested with Spring-Boot Swagger. To monitor these modules' health, the Spring-Boot Actuator provides secure endpoints, such as /metrics, /env, /beans, /trace, /health, and /info, which are protected by a role-based authorization scheme. The eCoach system can be accessed by both versions: a smartphone mobile app. (android) and a web. The ''/ecoachui/home'' and ''/ecoachui/'' APIs are exposed to the external user (but protected with VPN access, a firewall, and SSL). Other APIs are protected with access-role to the TSD platform. The user interface module is responsible for app view, web view, and data visualization based on individual access roles. We focus only on establishing a secure digital health infrastructure, eCoach security implementation, and security verification in this study. Concepts such as sensor description, processing of time-dependent (activity, nutrition, habit) and time-invariant (demographic) data, data visualization, and the implementation of HAPI-FHIR (HL7 V. 4) are beyond the scope of this paper. Figure 2 and Figure 3 depict how the security solution for the eCoach system has been developed with the TSD platform for the smartphone app. version and web version, respectively. In smartphones, all the personal and persongenerated health data (e.g., activity sensor data, questionnaire, and interview) are collected with an android eCoach app. and transferred to the eCoach services hosted in the TSD infrastructure for storing in the TSD central database. Using web version, only questionnaire and interview data can be captured and recorded in the TSD database. From TSD, access to the external server is prohibited. Therefore, the weather module is deployed outside of TSD infrastructure; however, inside of a VPN (EduVPN) and firewallprotected ubuntu infrastructure (EduNet), provided by UiA to access external resources as Weather APIs. Weather data collected from Weather APIs are stored in a PostgreSQL relational database inside EduNet. Networks inside EduNet are accessible (e.g., SMTP-mail.outlook.com); however, they must go through a proxy for external access. We deployed the following three variants of the Scheduler module: (the first one or v.1) inside of the TSD (for scheduled notification generation and storing the result in the TSD database as a notification message), (the second one or v.2) inside of the EduNet (for periodic notification message collection from TSD, combining it with the weather forecasting for contextual recommendation generation, and store the personalized notification message in TSD), and (the third one or v.3) inside of the eCoach mobile application (for periodic activity data transfer to TSD and periodic notification message collection from EduNet to generate notification pop-up alerts). Personal and person-generated health data inside the EduNet is protected and free from identity disclosure. Moreover, our eCoachUI module has two deployed versions: (v.1) inside of the EduNet (user interface for eCoach Web version) and (v.2) inside of the mobile application as a user interface.
Only activity, scheduler (v.1), eCoachBusiness, and the fhir sub-modules are deployed inside TSD. TSD exposes their endpoints under the following three services: /v1/p1075/ecoach/activity, /v1/p1075/ecoach/scheduler, and /v1/p1075/ecoach/fhir. These services are protected with OAuth2. The FHIR service is responsible for giving access to HAPI-FHIR REST APIs for semantic and structural interoperability. On the first installation of the eCoach mobile app, participants must register a system-generated user-identifier that will be stored in the smartphone's in-memory storage (or SQLite database) with the Bcrypt encryption algorithm. The user-identifier will help in session management and the transfer of personalized activity data. With the de-registration of the eCoach app., it will be auto removed from the mobile. SQLite database will be further reused to store valid shortlived (30 days) access tokens for TSD authorization. Inside EduNet, we created a self-signed SSL certificate with Keytool (keytool -genkey -alias apache-tomcat -storetype PKCS12keyalg RSA -keysize 2048 -keystore eCoach.p12 -validity 3650) to secure confidential web information using public key (RSA) encryption. The Keystore file path was then inserted into the configuration file of the Apache-tomcat webserver to alter the application start-up port from 8080 to 8443. The eCoach prototype system consists of five user types: researcher, developer, system admin, health professional, and participants. These users are grouped into ADMIN (researcher, developer, system admin) and USER (health professional or nurse, and participants) for role-based access management. Researchers and developers are responsible for eCoach design, development, test, and validation study. An ADMIN is responsible for infrastructure support. They have no access to participant's PGDs and dashboard. Trained health professionals (e.g., professional nurses) are responsible for offline interviewing to facilitate participant screening and collecting initial and baseline data. Furthermore, they can view the dashboard to monitor the participant's health status and health progress. Participants have access to their selfreporting questionnaire, feedback forms, and health monitoring dashboard through the eCoachUI module.

C. METHODS FOR SECURITY IMPLEMENTATION AND PERFORMANCE EVALUATION
There is no single protection method to meet all the security and design requirements for our modular and distributed eCoach prototype system. To realize and justify the adopted security solution, we applied a web engineering security methodology proposed by Aljawarneh et al. [49]. The software engineering principles encourage the method built up on top of the standard waterfall system development life cycle (SDLC). The applied approach reduced substantial threat exposures during all the SDLC phases by integrating security and assessment factors at each SDLC phase which software engineers and security professionals verified.
To determine the performance of the adopted security approach, we evaluated the API scalability. Throughput and latency were considered to measure the API scalability [53], [60]- [62]. Network throughput refers to the average data rate at which data or messages are successfully delivered on a specific communication link. It is measured in bits per second (bps). The maximum network throughput equals the TCP window size divided by the communication packet's round-trip time (RTT). The method does not consider communication overhead, such as network receiver window size, machine limitations, or network latency [53], [60], [61]. Network latency is the time taken for a packet to be captured, transmitted, processed through multiple devices, and VOLUME 10, 2022 then received and decoded at the destination [53], [60], [61]. We generated HTTP request loads to check API scalability as a ''Thread Group'' with Apache open-source software JMeter (V 5.4.1) and captured corresponding throughput and latency. For the load testing with JMeter [53], the following three properties have been considered critical: the number of threads or users, the ramp-up period in seconds, and the loop count to set the test count. We repeated the experiment multiple times with a loop count value of five for individual load and took a mean throughput and latency. Low latency and high throughput are good performance indicators to support real-time critical applications.

V. SECURITY IMPLEMENTATION SCHEME
This section describes our security solution implementation and then its validation. We demonstrate security configuration, sequence diagrams for user registration, authentication, authorization, application deployment, and the login process to access web resources from the TSD as IaaS (Infrastructure as a Service). We tested the security performance of the system in a real-time environment.

A. HYBRID SECURITY SCHEME AND ITS DEPLOYMENT IN THE ARCHITECTURE
For Linux VMs, TSD uses Thinlinc remote access protocol based on HTML5, with a Nginx proxy for two-factor authentication. Thinlinc is a remote desktop framework that supports HTML5 to connect to their Linux machines using their browser instead of a VNC client. Thinlinc uses TigerVNC and provides an additional layer of user and agent VM administration, allowing the automatic assignment of project user-groups to Thinlinc agents installed on the Linux VMs. Thinlinc infrastructure consists of a Thinlinc proxy and a Thinlinc master. The proxy runs Nginx and a customized log-in protocol. The Thinlinc master server is the machine where the users are redirected to after authenticating through the proxy. The master acts as the broker, keeping track of all the Thinlinc agent machines, and redirecting users to the correct agent machine. Users need to do an extra login on the actual project VMs. Each service deployed inside of TSD platform (e.g., /v1/p1075/ecoach, /v1/p1075/scheduler and /v1/p1075/fhir), is associated with a unique long-lived API Key ({''api_key'' = <key>}).
The keys are valid for one year and expire automatically. It is the responsibility of the system administrator to order a new key with an application-specific (e.g., eCoach) client_id and password (superuser). The key is just a JWT token, therefore, it can be decoded to verify if it has expired or not. The API key is used as a bearer token in the HTTP request header to generate short-lived access token (valid for 30 days). The admin can request five long-lived API keys in total. If anyone abuses the API, then long-lived API token is revoked. The complete API Key generation, sign-up and login processes are as depicted in Figure 5 and Figure 6.
TSD has pre-defined access tokens to investigate which access tokens are theoretically available to give clients access FIGURE 5. Admin sign-up and API key generation for TSD exposed services. to the specific API (GET /v1/p1075/auth/tokens/info). TSD API supports the following two authentication methods: basic and two-factor authentication. In the former, using just the API key, users can get the short-lived access token to their application to import data to TSD for the project to they have consent. Applications using basic authentication cannot export any data. In the latter, a google authenticator-based OTP is required to import data to TSD and export data from TSD. Both the authentication headers are explained in Textbox I.  TSD's network is strictly firewalled, and internal IP addresses are not published to external DNS services. TSD has a hierarchy of three DNS servers, two UNBOUND (the resolves for the addresses inside TSD) and one BIND being the source of authority and responds to queries from TSD and UiO resolvers outside TSD (having only the IPv6 addresses). TSD servers will not be able to ping or do DNS lookups on addresses outside the primary firewall by TSD. There is no Internet access to and from the project VMs, but we can communicate between hosts within the project's network, either from the login node or the service host itself. We can perform HTTP requests to the services once they are up and running through a given proxy. All the applications hosted on the TSD project VM are secured automatically and accessed within the TSD network and cannot be accessed from the external network. To access the APIs of our hosted services within TSD, we need to follow the steps depicted in Figure 7.

Textbox I The Authentication Headers in the Request Header
Our eCoach modules were first deployed into a test server (see Textbox II), and then it was hosted on the docker container in the VM in TSD (see Textbox III). The direct connection between the TSD environment and the outside internet and vice-versa is not possible due to the security policy of TSD. Thus, we are unable to use the internet functionalities from inside the VM and cannot access the docker hub to pull the docker images of the developed application. Hence, we need to follow an utterly offline procedure to build a docker image, upload it on TSD using their proprietary file upload procedure, load the image in the Docker container, and run it as depicted in Figure 7. TSD provides PostgreSQL and MSSQL as the DB services. TSD has mirrored the UiO setup for DBs inside TSD, and every project in need of a database (DB) will get its VM with a DB on it. The DB uses block device storage from the HUS-VM, and there are four DB administration computers. All DB traffic is encrypted and uses SSL certificates from Uninett. For this project, p1075-dbpg01.tsd.usit.no PostgreSQL DB host is created and opened from the p1075-service-l.tsd.usit.no service host. According to the security policies from the TSD on the PostgreSQL server, we do not have superuser privileges. TSD admin team can create application-specific databases and DB-owners. This restriction is done to guarantee a proper backup of PGDs. These DBs are only accessible from inside the VM from the service host and the applications hosted in the TSD but cannot be accessed from the public internet.

Textbox II Prerequisites to Deploy eCoach Modules Into the Test Server
Setup the working environment with JDK 8.0+ version and Apache-Maven build tool (V 3.X) Download a module (e.g., activity) from GitHub with clone or if its existing in the local codebase then perform pull operation. Install the latest version of Apache-tomcat webserver (e.g., V9.0.3). Create a database namely ''ecoach'' in PostgreSQL (e.g., V13.0) Create a TSD acts as an authorization server (AS) in the OAuth2 workflow. An authorization point works on the AS, allowing our applications and HTTP endpoints to define our system's features. In our eCoach system, two actors who interact with   the AS are -ADMIN (resource owner) and USER (client registered with AS) as the fundamental use cases depicted in Figure 8. The resource server is an application that provides clients with an access token to access the HTTP endpoint resource server. It is a library set that includes HTTP endpoints, static tools, and interactive web pages. OAuth2 is a mechanism for authorization to allow access to the client resources. We focused on the grant form (authorization code), client ID, and client secret to create an OAuth2 application.
JWT Token representing the claims between two parties is a JSON Web Token [25]- [27]. Such tokens are of two types: identity token (part of the OpenID Connect specification that is a client-dedicated function namespace) and access token (part of the OpenID Connect and OAuth2 specification and allows HTTP request that grants access to the service being invoked on). We used asymmetric key encryption ES256 (SHA256 with ECDSA algorithm) to create a JWT signature. Access tokens are typically short-lived and frequently expire after only minutes. The additional refresh token sent by the login protocol allows a new access token to be accessed by the application after it expires (see Figure 9).

A. EXPERIMENTAL SETUP
Security testing method is intended to show vulnerabilities in an information system's security mechanisms that protect data and retain functionality as expected. Security assessments are carried out in many ways to verify security features. Here, we used unit testing as a security testing method. Unit testing was performed with Spring-Boot Swagger and Mock MVC framework (Mockito) to validate the security functionalities of different eCoach modules [50], [51]. In addition, we set up Apache JMeter to perform scalability testing of the adopted security solution in a digital health infrastructure. We executed the security solution in a Linux environment (see Table 4), protected with a VPN and network firewall. All the essential HTTP headers for the API testing are specified in Table 5.

B. EXPERIMENTAL RESULTS
This section discusses adopted security considerations, scenarios, and experimental outcomes. Experiments related to CSRF, XSS, Clickjacking, content sniffing, and brute force were performed with Mockito framework (v3.9.0), Swagger (v2.2.1), and curl system command (v7.76.1). In our Spring codebase (v2.4.5), we created five functional test cases with Mockito for TSD basic (client_id + password) user authentication, TSD two-factor user authentication (client_id + password + OTP), and role-based authorization (OAuth2) with an access token. We further implemented a negative test case where the user received an expected error response code HTTP 401 for an unauthorized resource API endpoint. Table 6 defines the combined result of Mockito test performance in a vanilla test setting where we compared our API response time with preferred, acceptable, and delayed response time in seconds (sec). The response metrics can be classified into the following categories -mean response time, peak response time, and error rate. We considered a preferred response time of 0.1 sec, an acceptable response time of <1 sec, and a delayed response time of <=10 sec. We received a mean response time in an acceptable time range for all the API responses.
The spring-boot application extends the security class Web-SecurityConfig to protect against CSRF attacks. The CSRF tokens are powerful, changeable, and created as session tokens with specific properties that cannot be calculated or predicted by the intruder. Both HTTP POST forms in the ''JSP'' or template files need to introduce the CSRF token. If it is a JSON call, the token must be added to the HTTP request header. Initially, we disabled TSD token-based security setup and extended Spring's default web security configuration. Next, we executed the following four test cases for CSRF attack with Swagger: CSRF disabled (valid credential, invalid credential) and CSRF enabled (valid credential and valid _csrf token, valid credential, and invalid _csrf token). Successful authentication resulted in an HTTP status code 200 or 201. However, we disabled the CSRF token generation in actual security solution implementation. The reason for disabling CSRF was that our developed spring-boot application would be exposed to the public in the future. Therefore, we replicated similar and more robust web security standards with TSD's two-factor authentication and access token-based authorization. The successful test results are captured in Table 6. To ensure protection against VOLUME 10, 2022  XSS, content sniffing, and Clickjacking we explored TSD's security defense. We tested the attacks with a client's HTTP POST request with a Swagger API call and investigated whether XSS, Clickjacking, and content sniffing securities are allowed in the response header: setup data and recorded response headers are shown in Table 7. XSS is a category of security vulnerability found in web applications as cross-site scripting. The XSS attack was blocked by setting the value as ''block'' to the ''X-XSS-Protection'' parameter in the HTTP response header. Clickjacking is a method of tricking a user into clicking on something other than what the user perceives, thus potentially exposing sensitive information or allowing others to gain control of their device while clicking on harmless items, such as web pages. We blocked the Clickjacking by setting the ''nosniff'' value to the ''X-Content-Type-Options'' parameter in the HTTP response header. Content sniffing (or media type sniffing or MIME sniffing) is a method of tracking and inspecting the content of a ''byte stream'' to determine the file format of the data within it. We blocked the content sniffing by setting the ''DENY'' value to the ''X-Frame-Options'' parameter in the HTTP response header. We enabled configurable security defense to ensure data protection against brute force attacks. According to our coding, the user will get a chance of a maximum of three login failures before their account gets locked. The account will be activated based on the request ticket. Our analysis uses Spring-Boot, a counter to increasing the number of attempts with TSD to model the case attacker to execute the brute force attack. We set up the data in Swagger and recorded the response headers. Table 8 describes the unit test result of the brute force attack against three test cases.    To perform scalability testing in JMeter, we selected an eCoach REST service with an approximated 1.19 KB of a request body, 448.3 KB of the response body, and a response time of 316 msec. (see Figure 10). Using JMeter ''Thread Group'' feature, concurrent threads or loads (X) were created with three different values of ramp-up seconds (Y) and a loop count value of five (Z). At each iteration, X * Z number of loads were created to capture mean throughput and mean latency time. The results are described in Table 9 -Table 11. A load is a numeric value representing a total number of concurrent requests or threads. The pseudocode used for scalability testing is described in Textbox IV. We have considered the following values for scalability testing; however, the range can be increased for the future studies: The result shows a direct proportion between throughput and load, and latency time and load. However, reaching a certain threshold, the throughput drops with increased load.   infrastructure. It is three-fold research. First, we conceptualize a secure solution with SFTSDH, VPN, network firewall, and SSL. Second, we implemented the solution for developing a digital health infrastructure where we deployed an eCoach prototype system. Third, we perform testing of the eCoach prototype system's REST API endpoints against the common functional security testing (see Table 12) and scalability testing. We created 17 test cases for 11 test scenarios to evaluate the effectiveness of our adopted security solution. The SFTSDH implementation and configuration in the eCoach system have effectively secured the eCoach APIs from an attack in all the scenarios. Moreover, we performed a qualitative analysis on the effectiveness of SFTSDH in Table 13, after comparing SFTSDH with Spring Security and other Third-party Platform (e.g., Keycloak, Okta). Personal health data governance using the SFTSDH security solution has fulfilled the GDPR compliance checklist as specified in Table 14. Therefore, the SFTSDH solution is safe from the typical external illegitimate flooding requests as the external or exposed eCoach services are protected by a VPN and a firewall.
Due to licensing and subscription constraints, we could not create a similar environment to the TSD infrastructure and deploy other solutions (e.g., SF + Okta, SF + Keycloak, or solutions identified in literature) to test scalability against throughput and latency. Therefore, we only performed scalability testing for our work under defined settings and obtained a promising result, as depicted in Figures 11 and 12. The result shows an optimal throughput and latency at X = 200.

Textbox IV Pseudo-Code for Scalability Testing
Step 1: / * Initialization * / L = {n | n is an integer, and n ∈ Z + } R = {n | n is an integer, and n ∈ Z + } C = {n | n is an integer, and n ∈ Z + } X ∈ L Y ∈ R Z ∈ C Step 2: / * Iteration and value capturing * / For i = 1 to size(Y) do y = Y(i) For j = 1 to size(X) do x = X(j) For k = 1 to size(Z) do z = Z(k) load = x * z / * calculate metrices * / Calculate throughput (requests/sec), error%, received data (KB/sec), delivered data (KB/sec), mean latency (sec) and add the results to a list (List) End End End Step 3: / * Iteration and metric value display * / For i = 1 to length (List) do display (List(i)) End Therefore, the digital health infrastructure with the SFTSDH solution can sustain a load of 200 * 5 = 1000 concurrent users efficiently.
Our future study will focus on the migration of the deployed services from EduNet to the TSD platform after resolving identified TSD constraints, such as accessing TSD endpoints from public network using wireless technologies, basic webpage rendering without authorization, calling third-party weather API from TSD, and generation of auto-notification inside TSD in a synchronous manner. Autonotification support inside TSD will further reduce scheduling overhead in the eCoach mobile application.

VII. CONCLUSION
An API endpoint is an interface that helps in exchanging data between services. The service can access the expected resources from the API to perform the necessary operations. It plays a vital role in ensuring the regular and safe operation of the services and systems. Therefore, one of the leading security factors in MSA applications is API security. eCoach's REST API endpoint security solution with the TSD platform implicitly guarantees the privacy of personal health data within our adopted SFTSDH solution scheme following the GDPR and NORMEN regulations. This research accomplishes a prototype of an eCoach system that uses MSA with the TSD platform to evaluate technology and security integration. The research results show that the adopted digital solution effectively protects the APIs and personal health data (stored inside TSD). This study can be used as a TSD integration manual to protect personal health data in healthcare research.