Single Sign-On

Single sign-on (SSO) refers to the practice of using a single authentication service to log into other services. Skuid’s implementation of SSO uses then XML-based Security Assertion Markup Language (SAML). This authentication protocol is used by many services to allow end users to log into an identity provider (IdP) that grants them access to multiple different services, known as service providers (SP).

With SSO, a log-in process can look like this:

  1. Users login once to their identity provider (IdP), where they enter their unique username and password for the IdP.
  2. After logging into the IdP, users typically see a list of all services they have permission to access.
  3. Users click on the desired service, and they are logged into the service without entering a username or password.

By ensuring users have one method of entry into various services, authentication becomes a more streamlined—and arguably more secure—process.

Both Skuid SFX and Skuid NLX can be used with the SAML protocol. By configuring Skuid for SAML, you can allow your users to login into Skuid with the click of a button. You can also authenticate your end users to data sources used in Skuid pages.


When using SAML to connect to Skuid—or your data sources—the actual screen-by-screen experience will vary depending on which single sign-on services you utilize. Work closely with an administrator who is familiar with SSO as a concept, as well as your identity provider of choice. Included in the collapsed section below is a reference of concepts, phrases, and acronyms commonly seen throughout this process.

Concepts and definitions to know [[]]

Single Sign-On (SSO): The actual process of logging into an identity provider to access multiple service providers.

Security Assertion Markup Language (SAML): An XML-based standard for SSO. Skuid only supports SAML 2.0.

Identity Provider (IdP): An application that defines your end users and which applications/services these users are able to access. Examples include:

  • Active Directory
  • Okta
  • Ping Identity
  • OneLogin

Additionally services like Salesforce and Google Apps may be used as IdPs.

Service Provider (SP): The services being accessed by the IdP. This can include Skuid, Google apps, Salesforce, or other services.

Assertion: The term used for the XML message IdPs send to SPs to authenticate. Assertions contain several necessary authentication values used for logging in, as well as user provisioning when enabled.

IdP metadata files: A file provided by an IdP describing what is contained within the XML of its authentication assertion. These files contain the following:

  • Entity ID: Tells the service provider who the IdP is.
  • Certificates: One or more security certificate used for identifying the IdP and encrypting/decrypting SAML messages.
  • Single sign-on location URL: A URL that the SP can redirect a user to in order to initiate SSO. If the user has not logged in to the IdP yet, they will be prompted to login, otherwise they will be redirected back to the SP’s ACS URL with an assertion.

Assertion Consumer Service (ACS) URL: The URL where an IdP will send an assertion for an SP to consume and properly authenticate users.

Service Provider Entity ID / Audience URI: The SP entity ID is a unique identifier for a service provider, often written in the form of a URI. Because of this convention, it’s common for this value to also be the service provider’s audience URI, which is states the intended audience of a SAML assertion. Audience URIs are also sometimes referred to as an audience restriction, referring to its use within the AudienceRestriction tag.

The entity ID and audience URI serve as verification mechanisms to help ensure an assertion is received by the appropriate service provider. Your IdP requires these values to properly send its assertions.

Federated SSO and Federation ID (FID): In federated SSO, the IdP serves as a singular entry point to a group—or federation—of applications. To accomplish this, the IdP and SP will typically communicate a federation ID, which is a trusted piece of data—known to both systems—that can identify individual users.

The SP will receive a federation ID from the IdP, and it will trust that the end user has been properly authenticated. In practice, this means some SPs will not require a password to authenticate a user if it receives the proper FID, and sometimes a password may not even exist.

SSO for Skuid SFX

Since Skuid SFX is a managed package installed within a Salesforce org, user management—and thus SSO—is handled by Salesforce itself.

To learn more about configuring your Salesforce org for SSO, read Salesforce’s Single Sign-On Implementation Guide.

After logging into Salesforce through an IdP, you can access Skuid as you would normally.