Rollout has an on-premise solution that provides additional security and full control over the patch deployment process. It provides two important on-premise features:
- Customer approval before releasing a patch to production devices
- Signing of patches using a company’s own private key
To ensure patches are not tampered with, and prevent a Man in The Middle (MiTM) attack, Rollout uses a private key / public key security mechanism. When a patch is created it’s signed using a private key. The SDK contains the corresponding public key which is used to authenticate the patch before it’s applied.
Initial One-time Setup
- Developer downloads the Rollout SDK installer to their local machine.
- Developer updates the Rollout SDK with the client’s own certificate (which includes the public key).
- Client installs the Rollout on-premise service on their own server.
- For more information, you can download a reference implementation
Creating and Deploying a Patch
- Developer logs in to Rollout.io
- Developer creates a patch and tests it using the simulator or test devices.
- When the developer changes the patch status to production, Rollout's back-end updates the patch's status to Pending Production and sends an approval request to the client’s on-premise approval service.
- When the client is ready to approve the request, the client signs the patch with their own private key.
- The client sends the patch back to Rollout to a pre-determined endpoint (more details available on the reference implementation's README.md).
- Rollout's back-end validates the integrity of the patch, then changes the patch's status from pending to production and deploys the patch to the cloud (CDN).
- When the client’s app is launched on a production device, the device makes a call to Rollout’s CDN and the device downloads the patch.
- Rollout’s SDK checks the patch signature using the client’s own public key (which included in the certificate provided by the client).
- If the patch is authenticated, it is applied to the app.