Requirements and considerations for installing Space

Introduction

This section contains technical information regarding installation aspects of the "ProAccess Space" software ("Space" hereafter), such as system requirements, connectivity considerations, etc. It is intended for advanced users (like SALTO distributors working in conjunction with IT teams) who have to deal with the software installation process.

Overview

Space is an access control software designed and produced by SALTO for managing SALTO-manufactured electronic access points, such as standalone electronic escutcheons, cylinders and online IP and RF locks.

In the diagram below, a basic scheme of the Space access control system is depicted, in which the following main components can be appreciated: the Space server machine, the client machines and the SALTO peripherals and access point devices.

System overview

Simplified scheme of the Space access control system.

Network component icons

Icon	Description
Space server	Contains the Space service and the SQL database (SQL DB). It manages and controls, in real-time, all SALTO online devices, for example, online doors that are operated using radio frequency (RF) technology. It also processes requests from Space clients.
Space client	Runs client applications, for example, Space and the Local IO Bridge.
Encoder	An encoder is an external device that reads and updates keys with access information, writes access permissions onto cards (keys). Encoders can be enabled for USB or Ethernet connections.
Electronic lock	Allows or denies access, based on the permissions of the presented key. These access point devices can be online or offline and are battery-powered. BLUEnet-enabled locks are equipped with technology that allows online capability whereas standalone locks need to be updated using a PPD device.
Portable Programming Device (PPD)	Communicates information to the lock such as door identification and configuration details. This device, which communicates with the locks using NFC, can also be physically connected to the locks. It is used to initialize and update offline devices. See PPD for more information.
Controller	Provides real-time access control. Managed by the Space server, the controller works as both an online IP door and as a card updater. Controllers can be connected to readers using a RS485 bus.
Gateway	A device intended to be used with access points where online connectivity is needed. Gateways connect to electronic locks enabling offline access points to become connected. A gateway acts as a bridge transferring information using end-to-end encryption to and from the devices behind it to the software.
Nodes and repeaters	Also known as extenders, repeaters and nodes allow the distance between a gateway and electronic locks to be increased. A node needs to be physically connected to a gateway using an RS485 cable, whereas SALTO BLUEnet repeaters allow for wireless communication.
JustIN Cloud	Acts as a bridge between the Space backend and the JustIN mobile app.
JustIN app	The SALTO JustIN Mobile app allows users to use their phones as a key. It ensures users can receive their key online, anytime and anywhere.

The following sections explain in more detail the hardware requirements and security issues to consider when installing Space in both the Space server and client machines.

Space server

The Space server represents the heart of the system since it hosts both the SALTO database and the Space service.

The Space DB contains data concerning the installation's access control system, such as cardholder permissions, lock audit trail, locking plan, etc.

Currently supported backend DB systems are MS-SQL Server and MS-LocalDB (more on this later).

The Space service, on the other hand, is a Windows NT service developed for the .NET platform. It provides the following two functionalities:

1. Performs real-time access control by managing and monitoring the online SALTO devices (both access points and SVN updaters).
2. Attends and processes requests from Space clients and integrators.

The Space service is configured through a setup tool called "ProAccess Space Configurator".

Hardware and system requirements

The hardware and system requirements for the Space server are as follows:

• Supported operating systems: Microsoft Windows 10, 11, Windows Server 2016, 2019, 2022. Both 32-bit and 64-bit versions.

• Database¹: Microsoft SQL Server 2012, 2014, 2016, 2017, 2019, 2022 and LocalDB. All editions supported, "Express" included.

• Microsoft SQL Native Client 11.0 (installed by default by the Space installer program).

• Minimum hardware: it mainly depends on the amount of IP devices (such as Ethernet encoders, gateways and CU5000) that will be managed by the Space software. As a rule of thumb:

  • Installations with less than 300 IP devices: a dedicated machine with at least two 2.5GHz CPUs and 8 GB RAM is required.
  • Installations with more than or equal to 300 IP devices: a dedicated machine with at least four 2.5GHz CPUs and 16 GB RAM is required.

In addition, a 1024×768 high-color 32-bit display (for working with the GUI webapp via browsers) is recommended.

• .NET framework 4.6.2 or later (included within the installer).

• Required hard disk space depends on the size of the locking plan and the purgation policy. A minimum of 5 GB is recommended.

• Machine name resolver (DNS): Space uses machine names (rather than fixed IP addresses) for inter-machine communications. In this regard, a machine name resolver (such as a Domain Name System or DNS) is required to correctly resolve machine names into the corresponding IP address.

• The date and time of the server machine must be correctly configured before the Space software is started. Otherwise, the performance of the online devices (such as RF locks) might be negatively affected.

• Required LDAP controls/extensions:

  • If cardholders or software operators are to be imported from your directory service (DS) to the Space DB via LDAP protocol, make sure that the following LDAP control/extension is supported by your DS or LDAP server: "1.2.840.113556.1.4.319". For example, Microsoft's Active Directory is known to support the specified LDAP control, whereas Oracle Directory Server Enterprise Edition (ODSEE) does not seem to support it.

Virtual machine considerations

In principle, the Space service (and its DB) may be installed and executed in virtual machines. What follows are important considerations to bear in mind:

• Make sure that enough CPU and RAM resources are dedicated. Any latency due to insufficient resources will negatively affect the interactions between the Space service and the online access control devices and end users.
• In case your host machine is equipped with more than one physical NIC (network interface controller), make sure that all the IP traffic from/to the Space software flows through the same physical NIC (otherwise you may have communication issues with online devices, such as CU5000).
• If your system is Windows Server 2012 R2 and have communication issues between the Space server and the SALTO IP devices, consider disabling the VMQ (Virtual Machine Queue) feature on NICs. See the following link for further details: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm

Communication ports and connectivity considerations

The Space service is not an isolated piece of software. On the contrary, the Space service opens several listening ports for those third-party systems interested in requesting access control resources and services (for example, hotel PMS). The other way around also applies, that's to say, the Space service may establish connections to third-party systems in order to get certain data or services from them (for example, MS-SQL Server or the SALTO cloud).

The diagram below shows all the communication ports managed by the Space service. For TCP/IP ports, the arrow symbol indicates the listening port to which connection is established.

The table below enumerates all the possible communication ports (and their default value) that may be used by the Space service depending on the integration type.

Connectivity scheme for Space

Connectivity scheme for the Space service - all the provided values for the TCP/IP ports are software configurable.

Ports and connections from and to the Space service

Some important considerations to bear in mind regarding connectivity:

• Make sure that the MS-Windows Firewall (or any other similar program with blocking capability, such as anti-virus) does not block the Space service. If necessary, add a new exception entry in the Windows Firewall to avoid blocking the Space service.
• Some firewalls are configured to automatically shut down TCP/IP connections that have a long period of inactivity, resulting in communication problems within the system. In order to avoid communication problems, make sure the firewall in place does not automatically shut down TCP/IP connections when the inactivity is shorter than:
  • 5 minutes for websocket connections.
  • 105 seconds for the Oracle Hospitality PMS (FIAS) protocol.

• Space embeds its own web server. No external web server (such as MS-IIS or Tomcat) is required.
• Support for HTTP proxy: you may configure the Space software so that all the HTTP communications (for instance, to the SALTO cloud) are forwarded to a proxy server.
• Connections to the SALTO cloud (that is, https://*.saltowebservices.com) are only needed if you are to use digital keys through the JustIN Mobile app.
• If you need to receive real-time notifications, consider using the "webhook" functionality rather than the "event stream" one: the former is more standard, flexible and secure than the latter.

Permission considerations

What follows are the permissions required for the Space software to work:

1. The Windows account under which the Space service is running (Space account herein) must have total access to the Space DB. The easiest way is to make that Windows account be a member of the DB_OWNER role within the Space DB.
2. The Space account must have total access to the Space root folder (C:\SALTO\ProAccess Space by default) and below. In addition, any other working folder (for example, used for exporting or importing files) must be also accessible.
3. In the last instance, in case HTTPS is to be used, the Space account must have access to the corresponding certificate.

The good news is that the setup program manages all the above settings for you out-of-the-box. Note that administrator privileges are required to launch the setup process.

In case of a fresh installation, the default Windows account for running the Space service will be the low-privileged built-in account "Network Service". Well, more precisely, its virtual counterpart:

NT SERVICE\ProAccessSpaceService

On the contrary, in case of a software upgrade, the setup program will be respectful and keep unchanged the current account of the Space service.

This default configuration and other settings may be modified at any time by means of the service configuration tool named "ProAccess Space Configurator". Note, however, that should you change the Windows account of the Space service to another one, you will need to manually grant it permissions to all the resources mentioned above, that is, the Space DB, the Space folders and the HTTPS certificate.

Other security considerations to bear in mind are as follows:

• It is recommended to use a passwordless account, such as machine built-in accounts like "Network Service". Otherwise, the Space service will stop working on password expiration.
• In order to use the secure version of HTTP (that is, HTTPS), you will first need to specify a valid certificate (use the "Space Configurator" to select one among the registered certificates within the server machine). Note that the selected certificate must also be valid in the client machines in order to: 1. avoid the "untrusted connection" warning message shown by the browser, 2. browsers to receive real-time notifications (such as door openings) from the server.
• Further considerations when the SALTO "Graphical Mapping" is used: the Space service will accept connections from the GM software only if it is working under trusted user sessions. In the case of a Windows domain environment, trusted users are members of the same Windows domain as that of the Space server: if the user is not regarded as a valid member by the domain controller, the client (that's to say, graphical mapping) will not be able to connect to the service.

If you do not have a Windows domain environment but a workgroup environment, you will need to create the corresponding user within both the Space server and the client station to have trusted connections.

Database considerations

There should be one, and only one, instance of the Space DB in the premise.

For the sake of performance, it is strongly recommended that both the Space DB and service be installed in the same server machine. Otherwise, any latency between both components will have negative impact on all the interactions with peripherals and frontend sessions.

The Space service may work with two types of DB systems: MS-SQL Server or MS-LocalDB. In the following paragraphs some considerations are explained concerning both DB types.

LocalDB

LocalDB is a minified version of MS SQL Server that offers a fast, zero-configuration installation. It is suitable for small installations (in general, where a single machine is used).

One restriction regarding LocalDB is that only connections from the local machine are accepted. This is not actually an issue since browsers in the client machines do not connect directly to the DB but to the Space service².

MS SQL Server

What follows are the most important considerations to bear in mind regarding MS-SQL Server database:

• As stated above, it is strongly recommended to have both the Space DB and software installed in the same machine.
• Make sure that the Space account is a member of the DB_OWNER role within the Space DB.
• Make sure that the compatibility level of the Space DB is SQL2005 or higher.
• Consider enabling SSL connection in the MS-SQL Server instance so that communications between the DB and the Space service are encrypted. This is recommended when the DB is not located in the same machine as the Space service. See Appendix C for further details.

In principle, the setup programs manages the first three settings above for you out-of-the-box.

Best security practices

What follows is a series of best practices for a secure system:

1. Make sure that the operating system in your server machine and workstations are up-to-date with the latest security patches. Of course, avoid using Windows OS that has been deprecated and for which no more support is provided by the vendor. The same applies for the MS-SQL Server software used for data storage.
2. Use a low-privileged Windows account for running the Space service. For example, NT SERVICE, or better, NT SERVICE\ProAccessSpaceService (by default in the setup program).
3. Keep the Space DB isolated by not granting any other user access permission to it. Only the Space service (aside the system admins) should have access to the Space DB.
4. For the sake of performance as well as security, it is strongly recommended that both the Space DB and service be installed in the same server machine.
5. In the MS-SQL Server, enable SSL for the DB connections. This is important when both the DB instance and the Space service are not located in the same machine.
6. Use secure HTTP (HTTPS) when connecting client browsers to the Space web server. Note that configuration of HTTPS is not easy and requires support from IT staff.
   • Use a Certificate Authority (CA) signed certificate. Self-signed certificates should be used for testing purpose only, never for production environments.
   • HTTPS uses SSL/TLS protocols under the hood to provide privacy and data integrity between two parties. There are several SSL/TLS versions but the only one currently supported by the Space software is 1.2. See Appendix A for further details.
   • Behind the scenes, cipher suites, which are sets of instructions that enable secure network connections through SSL/TLS, provide a set of algorithms and protocols required to secure communications between clients and servers. Although there are several cipher suites in existence, the only ones currently supported by Space are the following:
     • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
     • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
     • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
     • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
     • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
     • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
     • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
7. If you need to receive real-time notifications from the Space service, it is strongly recommended to use the HTTPS-based webhook functionality rather than the "event stream" functionality, as the former is more standard, flexible and secure.
8. If Space authentication is used, make sure an appropriate password policy is enabled (for example, passwords letters, numbers and symbols). You can also consider using LDAP authentication for logging in to the Space software.
9. For a more secure login, it is recommended to activate the two-factor authentication (2FA) feature³.
10. Make sure also that the auto-logoff feature is enabled so that the user session is automatically logged off after inactivity is detected for the specified amount of seconds.
11. Back up the Space database on a regular basis (daily at least).This is essential for disaster recovery, business continuity and information security. It is strongly recommended to store the copies off-site.
12. Do not expose Space directly to the internet. As it is known, the internet is not an entirely secure environment and can expose the software to potential security risks. Therefore, keep the software within a secure network environment to ensure its safety and reliability. If you need to access Space from remote points through the internet, use VPN instead.

Client machines

Client machines just need a web browser to start interacting with the Space service. There is no need for any extra software except when you need to work with USB devices. The following subsections explain in more detail all the considerations regarding client machines.

The Space webapp

Web browsers are the window from which to interact with the SALTO Space software. The default URL to connect to is:

http://{{host_machine_name}}:8100

where {{host_machine_name}} is the name of the server (in which the Space service is running).

What follows are the system requirements for the Space frontend:

• Web browser: any browser that complies with HTML5. For example: Chrome, Firefox, Edge, Safari, etc. Internet Explorer is also supported though not recommended due to its low performance. No Silverlight required.
• Hardware: 1-GHz (or higher) CPU and 4 GB of RAM.
• Operating systems: if your client machine is to manage USB devices (such as PPD or card encoders), then Windows is required since the Bridge program (explained in the next section) only supports Windows machines (Windows 8, 8.1, 10, 11, Server 2012, Server 2016 or higher). Otherwise, if no USB device is to be connected, then any operative system can be used.
• Adobe Flash Player plugin for the webcam: if you are to use a webcam for making photos to cardholders, chances are you may need to have the Adobe Flash Player plugin installed within your browser. The following table indicates whether you will need the mentioned plugin depending on both the type of browser and the type of http connection.

The webcam may require the Adobe Flash Player plugin depending on the type of browser and HTTP connection.

One final consideration to bear in mind is that the Space frontend has been designed for desktop machines. Although it may work OK in iOS or Android mobile devices, the UX experience in these types of devices is far from optimal.

The "bridge" program between the Space service and USB devices

Web browsers impose multiple restrictions (due to security reasons) to web applications when it comes to use local system resources, such as USB ports. This is why the Space webapp cannot get access to USB ports, and thus, to the SALTO USB devices attached to them (like PPDs or card encoders).

SALTO provides a solution for this problem: the so-called "Local IO Bridge" program. This is a tiny Windows NT service that must be installed in only those client machines to which SALTO USB devices must be connected.

The "Local IO Bridge" program can be installed from the Space webapp (that is, from the browser). You can also find a copy of this program under the ..\dist folder in the server.

The "Local IO Bridge" program, as its name implies, works as a "communication bridge" between the Space service and the USB device.

This is accomplished firstly by establishing a TCP/IP connection to the Space service and secondly by opening the USB port to which the SALTO device is connected. Once both endpoints are open, the "Local IO Bridge" does nothing more than retransmit messages from one endpoint to the other. The final result is that USB devices are being remotely controlled by the Space service in the server.

In summary, what follows are the main considerations for the "Local IO Bridge" program:

• The installer of the "Local IO Bridge" program can be downloaded from the Space webapp (from the web browser). A copy of this program can also be found in the ..\dist folder in the server. Installation is simple and straightforward.
• The "Local IO Bridge" requires .NET 4.0 (the installer will automatically install it for you if it is missing). The operating system must be Windows 8, 8.1, 10, 11, Server 2012, Server 2016 or higher.
• The "Local IO Bridge" can be installed from the command line in silent mode, that is, in an unattended mode⁵. This helps the automatized deployment of the program in client machines. For this purpose, you must use both the "quiet" and the "installDir" switches, as shown in the example below:

C:\setup_saltolocaliobridge.exe -quiet -InstallDir= "C:\SALTO\ Local IO Bridge"

where the "installDir" switch must be followed by the path of the destination folder.

• Every time a communication process is needed between the local USB device and the Space service in the server (for example, for reading a card at a SALTO card encoder), a TCP/IP connection is established from the "Local IO Bridge" program to the server. The default target TCP/IP port is 8102 though it can be configured to another value if desired. See also Ports and connections from and to the Space service.
• In addition, the "Local IO Bridge" program opens two listening ports to which the Space webapp (running within the browser) is connected. Their port numbers can be any value within the range 50000-51000.
• Make sure that the "Local IO Bridge" program is running (as a Windows NT service) before working with USB SALTO devices. The Space webapp will show you a warning message if it detects that the "Local IO Bridge" program is not available.

Ports and connections from and to the "Local IO Bridge" service

Appendix A: Security protocols and cipher suites for HTTPS

HTTPS uses SSL (Secure Socket Layer) or its newer version TLS (Transport Layer Security) under the hood to provide privacy and data integrity between two parties. The Space software supports SSL/TLS by means of a Microsoft library called Schannel.dll, which is part of the Windows platform (including Windows 10, 11, Server 2012 R2, Server 2016, etc.).

The Schannel library supports several versions of SSL/TLS (including SSL v2.0, SSL v3.0, TLS v1.0, TLS v1.1, TLS v1.2 and TLS 1.3) as well as several cryptographic algorithms.

In principle, the Schannel library will automatically choose the best protocol and cryptographic algorithm depending on the capabilities of the client and server. However, you can configure Schannel.dll to control the use of specific version of the SSL/TLS protocol and cipher suites. This configuration is done by setting certain registry keys in the Windows registry as explained in the following Microsoft article:

• https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols-in-schannel.dll

Note that this security configuration is machine-wide in scope and cannot be configured on a per-application basis. This means that changes in the Schannel configuration will affect all the applications using the Schannel library.

Direct manipulation of the registry keys is not easy. A more comfortable way to configure the security options is to use a tool from the "Nartac Software" company called IISCrypto:

• https://www.nartac.com/Products/IISCrypto
• https://www.nartac.com/Products/IISCrypto/FAQ

IISCrypto is a free GUI tool (see screenshots below) created to simplify enabling and disabling various protocols and cipher suites.

Appendix B: Provision of certification for HTTPS

Provision of HTTPS certifications in LAN environments is not an easy task and should be performed by trained IT staff. This section is by no means an exhaustive manual for creating and installing certificates for the Space HTTPS endpoint but rather a simplistic guide. The picture below shows the main steps:

1. Create a corporate certificate authority (CA). If you don't already have one, start by creating your "root" CA (it will be a self-signed certificate). Specify the values for fields like expiration, keys, hashing algorithm, etc.
2. Distribute the created corporate CA among client machines. The certificate must be added to the trusted root certification authorities store.
3. Create the Space certificate and sign it with the corporate CA. The field that matters most within the Space certificate is the "Common Name". That is where you supply the hostname of the Space server ("Server01" in the example)
4. Install the Space certificate in the Space server. If necessary, grant the Windows account of the Space service access permission to the certificate.
5. Configure the Space software (with the configurator tool) to use the Space certificate.

Provisioning of HTTPS certifications

Appendix C: Configure MS-SQL Server to force encrypted connections

What follows is the way to configure the server to force encrypted connections with DB clients (see pictures below):

1. In SQL Server Configuration Manager, expand SQL Server Network Configuration, right-click Protocols for {{server_instance}}, and then select Properties.
2. In the Protocols for {{instance_name}} Properties dialog box, on the Certificate tab, select the desired certificate from the drop-down for the Certificate box, and then click OK.
3. On the Flags tab, in the ForceEncryption box, select Yes, and then click OK to close the dialog box.
4. Restart the SQL Server service

Further details:

https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-sql-server-encryption?view=sql-server-ver15#to-configure-the-server-to-force-encrypted-connections

Footnotes