Devolutions Hub's encryption service streamlines access to Hubs by eliminating the requirement to individually invite each user from an SSO provider. This feature can be enabled in Devolutions Hub under Administration – Authentication – Encryption service.
While Devolutions Accounts are always required with Devolutions Hub, the encryption service is designed to provide a simple and user-friendly experience. When users log in through SSO, the service automatically creates their Devolutions Account using the information from the SSO provider and retrieves the encryption key from the service itself.
If the user’s Devolutions Account already exists, the system will recognize it and provide the necessary key without requiring further action. For this to work as intended, you must configure the encryption service within your tenant.
Even with a configured SSO, accessing sensitive data still requires entering a password, answering a push notification, scanning a QR code, or fulfilling any another confirmation prompt deemed necessary to respect the zero-knowledge principle. Installing the encryption service allows you to circumvent this measure.
There are two ways to set up the encryption service:
The Azure template method, which is recommended as it is the more straightforward approach.
The Devolutions Hub Services method, which, although more complex, can be a suitable alternative for specific use cases.
If users experience issues connecting while the encryption service is activated, it is possible to restart the App from the App Service page to attempt to resolve the problem. If the issue persists, try stopping the App Service. However, be aware that users without a password will need to create one and will require an invitation to access the Hub.
To access the logs, go to the Deployment Center from the App Service page by selecting it from the left-hand menu, then navigate to the Logs tab. It is recommended to send these logs when opening a support ticket for assistance.
Should you experience issues during the encryption service’s configuration, know that you can stop the service in Azure at any time. This causes the Devolutions Hub to fall back to regular SSO login, and ensures that it can still be accessed by its users without disruption.
Q: What is being saved or stored by the self-hosted Encryption service?
A: The private and public key pair is generated in the browser and never saved nor stored anywhere. The Encryption Service only receives the public key to allow the authentication flow to continue.
Q: What would happen to existing encryption keys should the self-hosted Encryption service be updated via Azure AD?
A: Redeploying fetches the latest container version; encryption keys are not saved anywhere and are therefore unaffected.
Q: Can the Encryption service be secured further?
A: Adding more layers of security is perfectly feasible here. Make sure that the service is able to reach –and be reached by–, Devolutions Hub and Devolutions Portal. The Encryption Service operates as a redirection in Devolutions Hub' authentication flow, allowing for automatic SSO provisioning, decrypting your Devolutions Hub key at each login, and eliminating the need for invitations.
Q: Can I create fallback encryption services?
A: Additional encryption services can be created, but a user must be able to connect and switch the URL in the Encryption Service settings. Otherwise, it defaults to the normal key decryption method. Logging out might be required here.
Q: Can I configure the Encryption service while others are using the Hub?
A: In principle, this should not pose any problems. It is recommended to plan changes to services in advance in order to avoid configuration issues, in which case it is better to deactivate the feature altogether while working on a fix.
Q: If a self-hosted server is required for the Encryption service, does this mean we have to host Devolutions Hub on a physical server or virtual machine?
A: Devolutions Hub does not have to be hosted on a server, only the Encryption service needs to be.
Give us Feedback