Using non-Google identities

Introduction

Out of the box, Workbench supports any user who logs in with a Google account (e.g., @gmail.com, or a Google-backed work account). Workbench can also support users who want to use Workbench with an enterprise identity provider. This will allow users to log in to Workbench using their regular corporate credentials and login experience. This will require initial setup and configuration, but once done, users with non-Google accounts will be able to use a majority of Verily Workbench features.

Adding an enterprise identity provider

Some Workbench licenses include support for a customer-provided identity provider. Enabling this functionality requires collaboration between the Workbench Support team and the IT team responsible for managing the customer’s identity/authentication systems.

Supported identity providers

The following enterprise identity providers are supported and can be configured for Workbench:

• Active Directory/LDAP
• ADFS
• Azure Active Directory Native
• OpenID Connect
• Okta
• PingFederate
• SAML
• Azure Active Directory

For more information, see Enterprise Identity Providers.

Configuration process

As an example, configuring an Azure Active Directory account in Workbench involves the following:

• Customer IT team registering a SAML/OIDC application directly in Microsoft Azure Portal
• Customer IT team providing Workbench Support details on domain name, client ID, client secret
• Workbench Support creating and configuring a connection to the application in Auth0

Please contact Workbench Support to initiate the process of IdP configuration.

Using a non-Google identity provider

Once configured, users can log in to Workbench with their non-Google identity provider by signing in with the “Email address” dialog shown below. Based on the email domain inputted, the user will be redirected to the relevant identity provider to sign in.

Capabilities and limitations

Once signed in, a user will be able to perform the following actions in GCP-backed workspaces with their non-Google account:

• Create, clone, and share a workspace
• Create controlled or referenced resources, e.g., GCS buckets and BigQuery datasets
• Browse resources and preview files
• Create and run cloud environments for JupyterLab on VertexAI Workbench Instance and Dataproc Spark clusters, as well as custom applications on Compute Engine instances
  • This includes applying pre-created autoscaling policies to an environment via the Verily Workbench UI
• Create and run custom environments on a Compute Engine instance

However, the following actions in GCP-backed workspaces will return an error for users without Google-backed accounts:

• Directly opening a BigQuery dataset or GCS bucket in the Cloud console, e.g., to run BigQuery SQL, browse a bucket directly in GCP
• Directly opening a VM in the Cloud console by clicking “Open in GCP," e.g., viewing Spark cluster jobs, accessing gateway components in the Cloud console
• Accessing additional gateway components for Dataproc beyond the default Jupyter component
• Creating autoscaling policies for a Dataproc environment directly in the Cloud console

Note: Users will be able to work with supported functionality in AWS-backed workspaces (including using the AWS Management Console) with any IdP that is configurable in Workbench.