SAML Authentication Overview

This topic refers to functionality that is only available to accounts on the Business-level or above plans. If you do not see the functionality described here, either your account or realm has not been configured to show it, or your account is not on one of those plans.

Security Assertion Markup Language (SAML) is an is an open XML-based framework used to exchange authentication and authorization data between an identity provider (IdP) and a service provider (SP). It provides a set of interoperable standard interfaces. As a single-sign on (SSO) method, SAML enables users to access and log in to multiple websites using one set of credentials. SAML is the link between the authentication of a user’s identity and the authorization to use a service.

Note: You cannot use exact forms with an account that is using SSO.

SAML and Quickbase

Quickbase supports version SAML 2.0.

SAML is part of an overall user governance solution for access management. Together, SAML and Quickbase form the authentication management piece of access management. Users enter their user name and password once and can then access and connect to multiple applications and systems.

As a realm administrator, you can enable user authentication to a Quickbase realm using SAML. Additionally, you can use SAML authentication to give approval status to any user in your realm, making it easier to automate application access restrictions.

You can still use Quickbase access control to limit user access and permissions within the realm.

When a user authenticates through SAML, signing in to Quickbase is handled through your corporate sign-in process. The browser only redirects to Quickbase after the user has been authenticated. There is no registration process as there is with the first sign-in using Quickbase authentication. When users who are not in one of your registered email domains attempt to sign in, they will be able to choose whether to use your corporate authentication or register with a Quickbase-specific password.

Note: If you implement SSO SAML authentication, then two-step authentication is not available. You must implement two-step authentication on the client within your sign-in portal or SAML IdP provider.

SAML authentication process

The basic steps to set up SAML authentication to Quickbase are:

  1. Configure an Identity Provider (IdP)

  2. Configure SAML within Quickbase, or as an alternative, contact Quickbase Customer Care or your Sales Engineer to assist you with configuration.

SAML authentication example

The following example describes how SAML, your IdP provider, and Quickbase work together.

  1. A request for Quickbase first checks for a valid browser cookie. If a valid cookie doesn't exist, Quickbase then forwards an authentication request (AuthnRequest) to your SSO login URL. Your company’s users are either prompted to sign in, or are automatically authenticated based on an existing sign-in.

  2. The IdP provider then sends an assertion (packet of security information) containing claim rules or attributes. Claim rules enable the handshake to take place between your system and Quickbase. Claim rules are case-sensitive and don't contain any spaces. To ensure that the format is case-sensitive without spaces, you should manually enter the following claim rules:

    • NameID – Important: NameID is the most critical claim rule for authentication and must be a unique identifier that never changes, for example, most companies use an employee ID as the unique NameID claim rule.

    • FirstName – This must match exactly with givenName.

    • LastName – This must match exactly with surName.

    • EmailAddress – This must match exactly with email-address

    • X509 Public Certificate – This must be the IdP's X.509 public authentication certificate formatted as a .CER file

  3. Upon receiving the assertion, Quickbase checks if the NameID exists in its directory.

    • If the NameID doesn't exist, then Quickbase checks the EmailAddress provided.

    • If the EmailAddress is found, then the new NameID is added to the record and paired with the unique Quickbase ID.

    In subsequent assertions, Quickbase searches again for the NameID, and if found, updates any new user metadata.

  4. If the provider assertion doesn't contain a recognizable NameID or EmailAddress, Quickbase automatically provisions the user and opens the Quickbase My Apps page, listing any apps to which the user is invited. If the user has no app invites, the My Apps page is blank.

  5. The newly provisioned Quickbase ID is paired with the assertion’s NameID, FirstName, LastName, EmailAddress, and X509 Public Certificate.

Related topics: