There are two different ways to use CockroachDB as a managed service and enjoy DBaaS benefits:
Customers have flexibility to create clusters using a mix of these offerings in their CockroachDB Cloud organization.
Previously, users could sign into their CockroachDB Cloud organization using either Github-based Single Sign-On (SSO) or credentials managed by CockroachDB Cloud. Users kept asking for more common SSO methods, though, and we listened: First, we launched the ability to sign up and sign in using Google and Microsoft. And now we are excited to offer a new SSO option: enterprise authentication for connecting any enterprise identity provider using either SAML or OIDC.
When application teams evaluate using CockroachDB dedicated or Serverless to store and manage their data, one of the first questions that come up as part of InfoSec or risk analysis is whether they could use their enterprise identity provider (IdP) for sign-in to the cloud console. Other related questions that we hear are:
Enterprise authentication addresses all of these concerns.
Enterprise authentication is a suite of capabilities rather than one feature, oriented towards addressing the InfoSec and risk-related requirements mentioned above.
This gives users the ability to configure an enterprise identity provider as an authentication method for a CockroachDB Cloud organization. This connectivity can be done using either SAML or OIDC, which are the two dominant authentication protocols across industries, and are followed by all popular identity providers (like Okta, [Azure] Active Directory, Google Workplace, Onelogin etc.). With this, users will be able to use their enterprise identity to sign-in into their CockroachDB Cloud Console from a page or URL unique to their organization. Any password policy, MFA and other enforcements configured at the identity provider level would automatically apply.
Apart from configuring the enterprise identity provider, an admin could enable or disable specific authentication methods for a CockroachDB Cloud organization. For example, if a company’s InfoSec policy mandates employee sign-in using Okta (assuming that’s their enterprise identity provider), while allowing for consultant sign-in using Google, an admin could enable only those two authentication methods at the organization level, while disabling others like Microsoft, Github and CockroachDB Cloud-managed credentials. Once configured, only Okta and Google sign-in options would be surfaced on the sign-in page unique to the organization.
We’re also thinking about the admin experience in addition to security and governance. To simplify user onboarding to a CockroachDB Cloud organization, an admin could choose to enable auto-provisioning at the organization level. If configured, the admin could share the organization sign-in page’s URL with the target users internally. When those users sign-in using the enterprise authentication method for the first time, we’ll automatically create user accounts for them, without requiring the admin to go through the invite flow per user.
If you don’t have a CockroachDB Cloud account yet, you could get started by creating one by following these instructions. Once the account is set up, refer to this document to enable Enterprise Authentication for your cloud organization. To connect an enterprise identity provider using SAML or OIDC, you should have access to the relevant configuration.