Single-Sign-On (SSO) is an authentication method that allows users to securely log in to multiple applications and websites using a single set of credentials.
A trust relationship will be set up between the SSO platform, defined as the identity provider (IdP) and an application (Assemble), defined as the service provider (SP).
Assemble Currently offers direct support of Auth0* Authentication Platform, Security Assertion Markup Language 2.0* (SAML) and OpenID Connect*.
In Assemble you will find SSO set up and settings within the admin settings under Integrations > SSO.
Start by enabling single sign-on and choosing the option that is relevant to your identity provider (Auth0, SAML or OpenID).
You will then be presented with the list of fields that Assemble requires in order to integrate with your identity provider. Within Assemble all the fields provided here are required for successful integration except for the ‘Allow domains’ field.
Definitions within the context
The domain is the Identity Provider endpoint that is used to service authentication requests.
Unique ID provided by your SSO platform.
Secret text that is used to confirm the connection between Assemble and SSO.
SSO login URL: A link to the Identity Provider where authentication takes place. A user will log in via the identity provider, and then will be redirected back to Assemble as that logged in user.
SSO logout URL: Used to log out of the Identity provider.
Identity Provider Certificate: This should be a Base64 encoded certificate data with no spaces, new lines, or comments.
When configuring OpenID, this specifies the Token Access URL endpoint.
When configuring OpenID, this specifies the “Resource Owner” endpoint, which typically refers to an authenticated account. The resource owner is the person who is giving access to some portion of their account.
In OpenID, a way of limiting system access on the Identity Provider by requesting access to additional resources, that may have been separated from default responses. such as Usernames, phone numbers.
You may wish to restrict SSO usage within Assemble to use only certain domains, this allows you to restrict SSO usage in Assemble to only your staff users and therefore would insert your organisation's domain into the field.
SSO/ identity providers can have a large range of names for the fields we require in Assemble, in the tables below we have listed a number of general examples that may help you to identify and match up the given fields.
SAML match up
SAML SSO platforms may refer to the field as
SAML Domain (issuer)
Domain, Audience, urn identifier, Issuer
Identity Provider Login URL
Identity Provider Logout URL
IdP Certificate (Base64 Encoded)
Custom claims are used within the identity provider (/central data management service) if you wish to retain additional account information such as first name/last name, postal address, phone number, on your central data management service, you can configure the name of the custom claim field so that the corresponding records are updated within Assemble.
Once you have entered all the relevant information correctly into Assemble click ‘Save settings’.
Will validate the config and start checks for if Assemble users exist within your auth0 platform. If Auth0 is unable to find a user or connect to the Auth0 service, an error will be produced.
Will start a pre-flight check which will require you to log into the SSO in order to activate your SAML SSO. In the event, the Identity Provider is unable to properly communicate with Assemble or if Assemble cannot find a user that belongs to the email claim provided by the Identity Provider, an error message will be displayed and the SSO configuration will not be enabled.
Errors during a pre-flight check:
No account was found matching the email address, please contact the organisation for assistance.
This means the email address asserted by the identity provider did not match with an Assemble account. This could mean the identity provider database has not been synced up with Assemble account data.
We could not get an email address from the identity provider, please contact the organisation for assistance.
This means that although the Identity Provider was able to communicate with Assemble, we were unable to extract the email address from the response. If the email address claim is being sent with a different identifying name, please specify the identifying name of the field within the “Custom claims” section of the configuration settings.
There was a problem signing you in with your provider, please try again.
This means that an error occurred between the Identity Provider and Assemble. The most common causes for this message are:
Some Identity providers may provide a slightly different issuer on SAML services compared to their standard authentication protocol; for example, Auth0 uses the domain name for its’ domain/audience setting in the standard Auth0 service, but the domain is prefixed with urn: in the corresponding SAML2 service setting. The issuer setting is highly specific; If the Assemble setting for the Auth0 example does not contain the “urn:” prefix, an error will be produced and the Identity Provider will fail to communicate with Assemble.
No checks are currently made at this stage and therefore you must take care to ensure your configuration is valid before logging out of Assemble to prevent being locked out.
SAML with Google Workspace
ACS URL: https://<your url>/auth/saml/cbacs
Entity ID: https://<your url>/auth/saml/metadata
Start URL: https://<your url>/portal
Name ID format: EMAIL
Name ID: Basic Information > Primary Email
You will also need to add a SAML attribute mapping:
Primary email -> “identity/claims/emailaddress”
SAML Domain (issuer) = Entity ID
Identity Provider Login URL = SSO URL
Identity Provider Logout URL = https://accounts.google.com/logout
IdP Certificate (Base64 Encoded) = Certificate 1
*Auth0 is an adaptable authentication and authorization platform.
* Security Assertion Markup Language is an open standard for exchanging authentication and authorization data between parties (between an identity provider and a service provider).
* OpenID Connect is a simple identity layer on top of the OAuth* 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
*OAuth (Open Authorisation) is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.