Scout Web

Describes the operational requirements for the Scout Web product

This article is for IT and security professionals

Technical Overview

Scout is a Web Application that is hosted by FMI for client access to Pulse Service Requests and to manage the communication and lifecycle of the subcontractor.  It is designed for the customers of facilities management, from students and faculty to nurses and radiologists.  It has a simple yet powerful interface that can be picked up without training.

Devices

Scout Web is a responsive web app designed to work on all devices.  IT requires a modern web browser running on a desktop or a mobile device. 
While FMI strives to support a range of web browsers, from time to time features of modern browsers will be required that will stop older browsers from working optimally.  As such, we provide support for the latest three (3) versions of Google Chrome, Microsoft Edge, and Apple Safari running on latest two (2) minor releases of Windows, MacOS, iOS, and/or Android.

Architecture

  1. Scout Web is a web application designed to be run in a browser.  It is delivered as a Single Page Application (SPA) and downloads all client code on first web access.  Subsequent changes are managed through API calls to the server (as opposed to web pages).
    1. Users navigate to a common URL and login using their credentials.  
  2. The web servers running Scout Web App work as an elastic web farm, where FMI can add any number of servers on the fly to accommodate capacity requirements. 
    1. FMI actively monitors the responsiveness of these servers and ensures adequate capacity for needs. 
    2. Auditing and alerts on these servers are continuously fed into our development cycle to improve the product over time.
    3. API calls are secured with Json Web Tokens (JWTs)
  3. API calls need to be sent to on-premise Pulse instances.  To achieve this while maintaining good security practices, all API calls are marshalled through the Scout Relay Server.   
    1. This server first makes an outbound connection to the FMI servers and establishes a connection.
    2. No inbound firewall rules need to be created which would weaken the on-premise security.
    3. The outbound protocol runs on a queuing protocol (AMQP) and not HTTPS, providing protocol separation security.
  4. The relay server executes the require calls against the on-premise Pulse SQL Server, with responses returned through the same protocol-separated response mechanism.