Corporate SSO with TileDB Cloud SaaS
When using the hosted TileDB Cloud service, you can set up corporate SSO to TileDB Cloud. Users associated with the domain name you specify (a domain that you control) will be able to log in to the service without having to separately register or create a new password.
TileDB Cloud connects to your login provider with OpenID Connect, which is supported by most SSO systems, including Google Cloud, Okta, Microsoft, PingIdentity, and more.
To enable TileDB Cloud login, you will need to create an OpenID Connect integration with your SSO provider and configure it to accept requests from TileDB Cloud. Then, you can register this application within the TileDB Cloud web interface to connect it to TileDB Cloud.
TileDB Cloud supports most standard OpenID Connect identity providers. These basic steps are shared across all identity providers. For more detailed instructions on how to configure a specific provider with these settings, see the identity provider–specific walkthroughs below.
- 1.Create an OpenID Connect integration.
- 2.Within your OpenID Connect integration:
- Add the redirect URL (sometimes called a callback URL) of
https://cloud.tiledb.com/auth/sso/callback/perdomain. This allows login details for this integration to be sent to TileDB. - Enable required scopes (if needed):
openid(should already be enabled)email(allows TileDB Cloud to access and verify the user’s email address)profile(allows TileDB Cloud to see the user’s name and basic information)
After you have set up the integration on your identity provider, you can configure it within TileDB Cloud.
First, create a TileDB Cloud organization for your company or domain. Users who log in via corporate SSO will be added to this organization.
Switch to your newly-created organization by opening your user menu in the top-right corner of the screen and selecting the organization in the pop-up.
Selecting the new corporate SSO example user from the user menu.
In the main navigation bar on the left side of the page, open the organization’s profile.
The link to the organization’s profile in the navbar.
Select “SSO connections” in the main toolbar on the page, and then click the “Add SSO connection” button to add your SSO connection.
The toolbar with the SSO connections option selected.
Enter the information from the OpenID Connect integration you just created. Click Submit to create the connection.
The “Add SSO connection” window, with an example integration included.
Once this is complete, you will see your newly-created integration in the list.
The example corporate SSO setup, with the domain created.
To protect the security of TileDB Cloud accounts, TileDB uses DNS to verify that the user claiming a domain actually has control over it. The final step in setting up your SSO connection is to set up the DNS to verify your domain ownership.
To start, click on the SSO connection you just created in the table of SSO connections. This will open a page with information on that specific connection.
The information for a single domain’s SSO connection.
Click the “DNS information” button to open up a dialog showing the information you need to set up in DNS.
The DNS information for SSO setup.
You can set up either a TXT record or a CNAME record to verify ownership of the domain. Create the new record at your DNS provider.
Approximately every hour, TileDB Cloud will run DNS checks to verify your domain. After you complete setup, you can click the “Run check” button to immediately check for verification. A new entry will appear in the table once this completes. Due to the distributed nature of DNS, it may take a while for the new entry to propagate (though it is often immediate).
The verification table, showing one failed verification (before setup was complete) and one successful verification.
When your domain is verified, users can now log in to TileDB Cloud using corporate SSO.
Leave this record in place. TileDB Cloud continues to verify the domain to ensure continued ownership. If the record is not found, SSO will continue to work for 1 week before SSO is disabled. (This prevents transient errors or accidental DNS record removals from immediately breaking SSO.) Even if SSO is disabled, re-creating the DNS record will re-enable SSO with no new configuration necessary.
These walkthroughs provide detailed steps for the “identity provider setup” section above for a few providers. TileDB Cloud supports other standard OpenID Connect providers beyond the ones listed below; for providers where we don’t have detailed instructions, you can adapt the generic instructions above to your provider.
To enable SSO, you need to first create an Okta OpenID Connect integration for your installation.
In the Okta administrative dashboard, go to Applications and click Create App Integration. A dialog box will appear to initially set up the application. Create an OIDC - OpenID Connect integration with application type Web Application. Click Next once these are selected.
Okta’s integration creation screen with initial setup options.
On the next page, give the integration a name (like “TileDB Cloud”) and set the sign-in redirect URI to
https://cloud.tiledb.com/auth/sso/callback/perdomain. You can also remove the sign-out redirect URI, which TileDB Cloud does not use. All the other settings on this page can remain the same.
The new integration, with the sign-in redirect URI set and the sign-out redirect URI removed.
At the bottom of the page, decide which users in your Okta organization should have access to TileDB Cloud. Only those selected users will be able to log in. Click Save to create the integration.
You will be taken to the page for your new integration.
The Okta application page for the new TileDB Cloud integration.
You now have all the information you need to set up TileDB Cloud:
- Issuer: Your Okta domain, for instance
https://ingen.okta.com, with no slash at the end. - Client ID: The client ID displayed on the page (in this case,
0oa90kw5r1pSVMyP85d7). - Client Secret: The client secret (currently hidden; a longer string which looks something like
Lby3LACsZewg_CzOCyG2CdGVWhXhZEfyDPcEKf30).
From your PingIdentity administration dashboard, enter the appropriate environment and click Connections → Applications in the sidebar.
The PingIdentity dashboard with the “Connections” menu in the sidebar (the thing that looks like an S) and the Applications sub-entry highlighted and opened.
Click the + icon to add a new application. This will open a dialog box for you to set up the OpenID Connect connection for TileDB Cloud to use. Give the application a name (“TileDB Cloud”) and select OIDC Web App from the options at the bottom of the page. Click Save.
The “Create Application” dialog, with the name TileDB Cloud and the “OIDC Web App” type.
After creating the application, you should now be on the configuration panel for your new TileDB Cloud connection.
The base configuration panel for the brand-new TileDB Cloud application.
Click the Protocol: OpenID Connect button to open the OpenID Connect configuration dialog. Add the Redirect URL
https://cloud.tiledb.com/auth/sso/callback/perdomain, leave everything else unchanged, and click Save. This will allow TileDB Cloud to process logins.
Click Overview to return to the main tab, and click the Resource Access: 1 Scope button. In the dialog that pops up, add the email and profile scopes to the application. Click Save here as well.
The “profile” and “email” scopes added to the TileDB application.
Now the entire setup on the PingIdentity side is complete! Use the Access tab to configure who from your organization has access to TileDB Cloud (if desired) and enable the application.
Don’t close up PingIdentity yet, though; we still need the Client ID and Client Secret for TileDB Cloud.
Return to the Configuration tab of the TileDB Cloud application in PingIdentity and expand the General zippy. (You may need to scroll down.)
The TileDB Cloud application configuration page, with the “General” zippy expanded.
TileDB Cloud needs three pieces of information from this page to successfully connect to PingIdentity:
- The Issuer, which is a URL that will look like
https://auth.pingone.com/[some-uuid-goes-here]/as. It does not have a/on the end. - The Client ID, which identifies TileDB to PingIdentity. (For PingIdentity, this happens to be a UUID.)
- the Client Secret, which allows TileDB to access PingIdentity resources (This is a random alphanumeric string.)
Last modified 2mo ago