Access to this feature can change based on your Quickbase plan. Learn more about feature availability and plans in Quickbase Plans and Pricing.
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.
The basic steps to set up SAML authentication to Quickbase are:
SAML, SSO, and realms
- No SSO (All users go through Quickbase auth)
- All SSO (All users go through a single SSO configuration)
- Some SSO (Some users go through a single SSO configuration, with the ability to set specific users to go through Quickbase auth)
If you use SAML and your "active client" also uses SAML, you'll need to decide which SSO configuration is more convenient for you and your company. Your IT team may be able to update the configuration for your identity provider to link to both your SSO and your client's, but that they would need to build that on their end.
SAML authentication example
The following example describes how SAML, your IdP provider, and Quickbase work together.
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.
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
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.
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.
The newly provisioned Quickbase ID is paired with the assertion’s NameID, FirstName, LastName, EmailAddress, and X509 Public Certificate.