Skip to main content
Skip table of contents

Setting up SSO with SAML 2.0

Single Sign-On (SSO) describes the process of authenticating a user's identity via your organization’s central identity manager and then granting access to all of the applications that the user is authorized to access via that identity provider.

Envizi supports SSO with your identity provider using SAML 2.0 authentication.

If your organization has been entitled for Single Sign-On (SSO), as a system administrator you can complete the SSO SAML 2.0 setup.

Note: currently not available to clients and is only available to implementation users with Partner Administration role. Once our implementation teams have more experience using this feature we will enable it for clients.

Setting up SSO

You will need to be a System Administrator in order to follow these steps:

  1. Go to Admin → Single Sign-On

  2. Click Create New SSO

Basic Metadata Configuration

  1. Add a name/description to identify your SSO setup

  2. Associate Name - keep the default value

  3. Client ID - keep the default value

  4. Entity ID - keep the default value (ensure that the url is …/home/ and not …/home1/ or …/home2/ etc)

  5. ACS URL / Reply URL - keep the default value (ensure that the url that is included is …/home/ and not …/home1/ or …/home2/ etc)

  6. Name ID format - keep the default value

  7. Click the button Build and Download SP Data. This option will build the SP Metadata, save the metadata and download a xml file of the SP Metadata. This file needs to be sent to your IT department in order for them to register the Envizi application in your organization’s Identity Provider in order to generate a certificate and provide the IDP metadata as XML or URL for input into Envizi.

The SP (service provider) metadata contains information like the Entity ID and the Assertion URL and some configuration required for the Envizi application’s SSO configuration. This metadata will need to be imported to your Identity Provider when registering the Envizi application for SAML.

SP metadata example:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2023-12-09T00:01:55.297Z" cacheDuration="PT604800S" entityID="https://<cluster>">
     <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
          <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://<<client_id>/" index="1"/>


Name ID (Name Identifier) must be formatted as email and must be the same as the username they will use to login into the system. Most IDP/organizations use the user’s email address as username and some uses a different username different from the email address.

Load IDP Metadata

The IDP (identity provider) metadata contains the registration from your identity provider including certificates for authentication.

  1. From the SSO Setup grid, select the Action (or right-click) Edit SSO Metadata

  2. Scroll down to STEP 2: Load IDP Metadata

  3. Select XML or URL. If its a URL, you will be prompted with a text box to enter the URL of the metadata. If its an XML file, you will be prompted to upload the file. The system will automatically read the contents of the file and display in the text box for review.

URL is the preferred option as any changes in your IDP are automatically reflected and you will not need to upload a new xml file.

IDP metadata example, this will be provided either as a file or via a URL:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="">
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="" />
        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" />
        <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="" />

        <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="" />
        <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" />
        <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="" />

        <ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="" index="0" />

        <KeyDescriptor use="signing">

        <OrganizationName xml:lang="en-GB">Example</OrganizationName>
        <OrganizationDisplayName xml:lang="en-GB">Example Org</OrganizationDisplayName>
        <OrganizationURL xml:lang="en-GB"></OrganizationURL>

    <ContactPerson contactType="technical">
        <EmailAddress>[email protected]</EmailAddress>

  1. Domain - leave blank if any users' email domains can be authenticated. If authentication is restricted to specific users' email domains, enter your organization's domain eg. %[@] or %[@.] Please ensure that you do not enter proceeding and trailing spaces.

  2. Toggle ON Enable Just-In-Time User Provisioning (if required).
    Note: If enabled, additional configuration maybe required in both Identity Provider and Envizi System. Please refer to the Just-In-Time User Provisioning.

  3. Toggle ON to Enable SSO when you have completed the above steps and you are ready for your users to login via SSO.

  4. Click Save and Load Metadata to save all your changes.

Preference for Disabled Users being able to login

If your preference is to use a Login’s Enabled status to control whether they can log into Envizi or not:

  • On the row of the SSO you are configuring, select the Action (or right-click) Edit SSO Metadata

  • Click on Other Attributes

  • Toggle the Fail Disabled Users setting to ON (yes). Click Save.

If this setting is switched on, users who are authenticated via your identity manager but have their logins in Envizi set to disabled will not be able to login to Envizi.

Additional Information:

When manually provisioning users, ensure that the username is the same as they appear in the identity provider. Some identity providers do not always use an email address as the username but they are formatted to look like an email address.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.