An Auth0 deployment that exists in a dedicated area of Auth0's cloud, your cloud, or your own data center.
The Auth0 Private SaaS (formerly known as Auth0 Appliance) is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. The Auth0 Private SaaS can be deployed in one of three places:
Auth0’s on-premises appliance option for deployment gives us a big advantage over pure cloud competitors. Some customers, whether because of compliance or regulatory demands or because of their specific use cases and threat profiles insist upon maintaining the infrastructure hosting their security components themselves. Many of these customers want ironclad SLAs with rapid response times, and want to maintain the most secure and up-to-date installations possible. At the same time, they’re dead-set against allowing any outside organization such as our customer support team to have direct access to their authentication infrastructure. These are mutually exclusive demands.
Our Private SaaS product is not something we sell, train their staff, then leave. It is a professionally managed service – they get the same expertise we deliver to our public cloud customers but running on their own infrastructure. It isn’t like buying a database from Oracle, or a server + operating system from Dell. But customers might be thinking that just like other enterprise infrastructure, if it is running in their data center or private cloud behind their firewall, that they can isolate the Auth0 appliance completely and Auth0 does not need access. This just is not how our product works. We’ve carefully crafted our access requirements to be the minimum necessary to deliver that professionally managed service – no more, but no less.
The Auth0 managed on-premises appliance requires regular access by our customer service team to keep it up to date, fix problems, and optimize security and performance. There is a trade-off between maintaining strict isolation behind the customer’s firewall, and the service level that we can offer. Customers cannot have both, to the max. But they can have a high degree of isolation and great service at the same time. Here are the choices, ranked from higher service level with Option 1 to greater isolation with Option 3.
But first a definition:
Jumphost: a server, also sometimes called a bastion host – can be a virtual machine – minimally configured with hardened security and local firewall to act as a secure communications relay system. Jumphosts typically have a static IP address such that a perimeter firewall can be configured to whitelist only that IP address and specific ports, to minimize the opening in the firewall and force access to a protected resource through the jumphost. A jumphost also serves as a convenient audit point – if all access to the protected resource must pass through the jumphost, then everything can be logged and audited.
Service: Auth0 can use SSH to securely connect to the appliance whenever the firewall rule whitelisting the Jumphost is in effect.
Isolation: End to end encryption (SSH). Whitelisted single static IP address for the jumphost. Can turn access on and off for Auth0 by enabling/disabling the whitelist rule in the firewall.
Service: Auth0 can use SSH to securely connect to the appliance whenever the jumphost managed by the customer is up.
Isolation: End-to-end encryption (SSH). No need to alter firewall rules when access is needed – just bring up/take down the customer’s jumphost. Firewall whitelists customer jumphost only
We’re confident that we will keep customer data safe. We’re also confident that our managed service is worth the risk. So we recommend that customers grant us limited access through a jumphost if they do not need a custom rapid-response SLA, or VPN access when they want to buy a custom response time SLA.