App Installation
The STP.Documents.OnPremise Mobile DESK is a Progressive Web App (PWA) and therefore works on any modern browser. Installation from an app store is not required.
To get the app on their phone, users can either scan the QR code displayed on the info page after successful installation of the agent—which can be sent by the firm admin via email—or navigate their browser to https://…stp-cloud.de/documents. The app can then either continue to be used in the browser or be pinned to the home screen. Pinning to the home screen is typical for PWAs. The app will then have its own icon and can be arranged alongside any other app.
User Login
After opening the app, the user must first log in. The user must enter their username and password to ensure they are authorized to use the app and connect to their tenant’s on-premise system. It is recommended to check “Remember login data” so that the login session persists longer.
During login, the system also checks whether the logging-in user is
linked to an on-premise user account in the on-premise STP
UserManagement. This link is important to ensure that requests to
STP.Documents.OnPremise are performed on behalf of the correct user.
Only data that the user is authorized to access in
STP.Documents.OnPremise can be requested.
If this link does not exist, the app will notify the user that they are
not known in the on-premise environment. The user can then be added to
the CloudAccess group in the on-premise STP UserManagement, which
establishes the link. Whether the link exists can also be checked in the
cloud user’s profile by double-clicking the email address.
Device Registration
After successful user login, device registration takes place. The secret key is used to establish an end-to-end encrypted connection with the agent in the on-premise environment.
On first use, the app automatically detects that no device is set up
yet and enters setup mode. By default, up to five devices per user can
be registered. It is important to compare the fingerprint of the agent’s
public key as displayed in the app with the fingerprint shown on the
agent’s info page or in the admin’s email. This ensures that the
end-to-end encrypted connection is established with the correct endpoint
(Trust On First Use).
A secret key and a public key are then randomly generated. The public
key is sent to the agent, allowing a secure connection to be established
between the app and the agent using cryptographic methods. The secret
key must not be made public and must be stored securely. The security of
the app is directly tied to the security of this secret key.
Key Management
For a web application, it is inherently difficult to keep a secret key confidential. The STP.Documents.OnPremise Mobile DESK supports three different mechanisms for this. These mechanisms offer varying degrees of security and convenience. Depending on risk and firm security level, a more secure or more convenient setting can be chosen.
Password Manager
The recommended way to keep the secret key confidential is to use the device’s password manager. All browsers support this mechanism. Password managers are designed to protect secrets and are therefore ideal for storing the secret key of the STP.Documents.OnPremise Mobile DESK. The secret key is treated like a 214-character password.
During registration, the user selects a device name. The secret key is generated automatically and must not be altered. When the user clicks the “Connect” button, the device’s password manager will offer to securely store the secret key. The user confirms this action.
If the password manager does not offer to save the secret key, make sure the password manager is active. On iOS, only the iOS Keychain can display this dialog, so it must be used to manage the secret key.
After the secret key has been saved in the password manager, the app will prompt the user to use it. To do this, the user clicks into the device name field and selects the secret key from the password manager. This ensures the secret key is correctly stored and can be used for logins. Registration is then completed. Authentication with the secret key is now successfully set up. The administrator must now activate the device so the app can establish a connection.
Each time the app is opened, the secret key can be loaded from the password manager into the app, allowing a secure connection to be established.
STP.SecretService
If the app is used in an environment where using installed password managers is difficult, this alternative can be used. The secret key is stored in a password manager hosted in the cloud by STP, called STP.SecretService. Since the secret key should not leave the device, it is first encrypted with a PIN and then stored only in encrypted form in the STP.SecretService.
To use this alternative, the yellow option can be selected during device registration. After clicking the “Connect” button, a PIN entry prompt appears instead of the password manager. The user can choose a PIN to encrypt the secret key. The encrypted secret key is then stored in the cloud and is available to the user for secure use. In the final step of registration, the encrypted secret key appears as a button above the input fields.
When the user clicks this button, the PIN entry prompt appears again. Only with the correct PIN can the secret key be decrypted. In this case, the secret key and device name are entered into the input fields, just like with a password manager. The user can then complete the registration. If the device’s password manager offers to remember the secret key at this point, the password manager dialog can be canceled, as the secret key is already stored in the cloud. The administrator must now activate the device so the app can establish a connection.
Each time the app is opened, the secret key can be used via the button above the input fields. To use the secret key, the correct PIN must be entered for decryption.
In the Browser
The secret key can also be stored directly in the browser’s LocalStorage, so that no further selection from the password manager or PIN entry is required when starting the app.
While this alternative is the most user-friendly option, it is also the least secure. The browser’s LocalStorage is cleared, for example, when browser caches are deleted. In that case, the secret key would be lost and the device would need to be registered again. Additionally, LocalStorage can be accessed by JavaScript, so in the event of a successful cross-site scripting (XSS) attack, the secret key could be read. The app tries to prevent XSS attacks by, for example, not using JavaScript directives known to be vulnerable to XSS. However, absolute protection cannot be guaranteed.
To use this alternative, the red option can be selected during device registration. After clicking the “Connect” button, only a warning message appears, pointing out the risks of this setting. The user can then complete the registration. The administrator must now activate the device so the app can establish a connection.
Each time the app is opened, the secret key is automatically loaded from the browser storage into the app, so no further input is required.