Community docs

SAML and

If your organization uses a SAML 2.0 compliant single sign-on (SSO) provider, you can configure a new SSO application with that provider (e.g., Okta, ADFS) to authorize access to your organization’s data. Once configured, all members of your organization will need to verify their identity through SSO before accessing resources.


In order to use single sign-on with SAML and you will need the following:

  • A SAML-enabled organization (requested from Client Success or Support)

  • An administrator login for the organization

  • A SAML 2.0-compliant identity provider

SAML application configuration

The first thing you will need to do is create a SAML application for You will need the following configuration information to create this application:

  • Logo image - This is the logo image for and it is found at

  • Single Sign-on URL/Assertion URL - The specific URL that SAML assertions should be sent to:{organization_id}. Replace {organization_id} with your organization's id which can be found in the URL of the organization homepage. For example the organization's ID for would be nightowlcorp , and would be democorp.

  • Audience URI/Entity ID - The unique SP identifier that dictates the entity or audience for which the SAML Assertion is intended:

  • Additional attribute statements - These are used to help identify the user and are composed of an Attribute Name and a Name Format. We require firstName , lastName, and email.

    The Name Format for is Unspecified. Examples of the Attribute Names for Okta and ADFS are as follows:

    • For Okta:

      • user.firstName - firstName

      • user.lastName - lastName

      • - email

    • For ADFS (no namespace URI):

      • user.givenName - firstName

      • user.surname - lastName

      • user.mail - email

Setup on

Follow these steps to configure to use SAML:


An administrator role in the organization on is required to make these changes.

  1. Go to the organization home page and select the Settings tile:

  2. Select the Settings tab and the Security menu item on the left, then check the box to enable SAML. If you don’t see a Security tab, contact your representative to enable it for you:

  3. Enter the information requested and select Test SAML configuration.

  4. Click “Save” if the test is successful. It may take a few minutes for the change to take effect for all org members.


When you enable SSO for an organization, members of that organization will need to validate through the SSO provider to access any pages on, not just the organization’s.

All users of the organization will have their personal API tokens reset when SSO is enabled.

  • If they have integrations (such as Python) set up with this token, they will need to update the token within the integration.

  • If they have saved any query results as tables within, they will not be able to sync those tables.  They will need to delete the tables and re-save the query results as a new table.

Using Just In Time (JIT) account provisioning

Just In Time (JIT) account provisioning is an optional feature that creates an SSO login portal to your organization on When this feature is enabled, you will have a SSO-enabled login page created at{your organization}/login.


If someone has the app assigned to them in their SSO provider profile but does not yet have a account:

  • a new account will be created for them automatically when they click the link on this page

  • their username will be firstname-lastname, based on the name that exists in their SSO profile

  • they will not be given a password - they will need to login using the same login page in the future and authenticate via SSO

  • they will be granted membership to the organization on with the Member level of organization membership

If someone has the app assigned to them in their SSO provider profile, has a account, and is a member of the organization:

  • they will be logged into if they have validated recently through the SSO provider

  • if they haven't validated through the SSO provider recently, they will be redirected to the SSO provider's login page, and then redirected to upon completion of the SSO login

  • they will land on the organization's homepage (as opposed to their individual account's homepage) upon login

If someone has the app assigned to them in their SSO provider profile, has a account, and is NOT a member of the organization on

  • they will be logged into, but redirected to their individual homepage.

  • they will not be granted automatic membership to the organization

  • an admin of the organization on will need to manually invite them to the organization

  • this case occurs when someone signs up for a account before SSO is enabled for their organization, or if they create an account on without using the special login page described at the top of this section

If someone does not have the app assigned to them in the SSO provider profile:

  • an SSO provider admin will need to add the app to the user's SSO provider profile

  • after is added SSO to the provider profile, they will be able to create a new account through the login page described in this section


When implementing SAML with watch out for:

  • If the Single Sign-on URL/Assertion URL ({organization_id} ) was entered improperly in the SSO provider’s configuration, users will experience a 404 page or a sign-on loop when trying to access