Skip to main content

Configure Single Sign-On (SSO)

Configure SSO for your INGENIOUS workspaces to improve security, save time, and increase productivity for users and organizations.

T
Written by Taylor Vickhammer
Updated over a week ago

Prerequisites

  • You must be an Administrator to configure SSO

  • Your organization must be using one of the following SSO providers:

    1. Microsoft Entra (Formerly Azure)

    2. Okta

    3. PingFederate

    4. SAML2

  • Workspace subscription type must be Enterprise to use the self-service SSO functionality. Please reach out to your CSM if interested in pursuing an upgrade or help configuring SSO authentication for your workspace.

Important Note: Email Address Consistency

For successful Single Sign-On (SSO) login, it is crucial that the email address associated with your account in our system precisely matches the email address used within your organization's SSO system.

For example, if your email in our system is `user@user.com`, the same `user@user.com` email should be used when logging in via SSO.

If a different email address, such as `user_sso@user.com`, is used in your SSO system, our system will be unable to recognize your account, and login will fail.

Please ensure email addresses are identical across both platforms to avoid login issues.

How to configure SSO in your Workspace

  1. As a company admin, Click on your initials in the bottom left -> Company Settings -> Password Management

  2. Select "Configure" on the SSO you would like to use in your workspace.

  3. Determine which fields are required from the specific SSO provider screen in INGENIOUS. Collect the required information from the SSO provider and input them into INGENIOUS. These can include:

    1. Base URL

    2. Client ID

    3. Client secret

    4. Tenant ID

    5. IdP Binding Method

    6. XML Metadata

    7. Assertion Consumer Service URL

    8. Service Provider Entity ID

  4. Once the SSO has been authenticated, you will be able to set the status of the SSO method to "Active". Once selected, you can inactivate the "Email/password" authentication.
    ​

  5. Once the SSO is configured, any users within your workspace who enter their email when attempting to log in will be redirected to enter their SSO information to access INGENIOUS.

Tip: Now that a user has successfully authenticated into the workspace via sso you have the option to turn off system password as an authentication option via the SSO tab in company settings.

Configuring SAML2 Metadata Attributes

When configuring SAML2 Single Sign-On (SSO), the setup includes an XML metadata file. This file must contain the correct attributes with the appropriate schemas.

⚠️ Important: Attribute names and schemas are set on the client’s SSO side. While there is a standard for SAML attributes, each client’s SSO system (e.g., PingFederate, Okta, Azure AD) can have slightly different settings.

Common Attribute Examples

Below are examples of how attributes and schemas may appear:

Example 1 (WS-Federation style)

<auth:ClaimType xmlns:auth="http://docs.oasis-open.org/wsfed/authorization/200706"      Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">     <auth:DisplayName>Email</auth:DisplayName>     <auth:Description>Email address of the user.</auth:Description> </auth:ClaimType>

Example 2 (SAML2 style)

<saml:Attribute Name="email"      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"      xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"/>

As shown above, schemas can be defined differently (NameFormat, Uri, etc.), but the values themselves remain the same. Correct mapping of these values is the most important aspect of SAML attributes.

Handling Attribute Names vs. Schemas

In some cases, the client’s SSO may not allow them to fully specify attribute schemas. For example, their metadata might only define:

NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"

If a client cannot specify schemas such as:

  • email = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

  • first_name = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

  • last_name = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

👉 Then the XML metadata must still contain the correct attribute names:

  • email

  • first_name

  • last_name

Tooltip suggestion:

Please ensure your XML metadata contains the correct attribute names and schemas. If you cannot specify schemas on your side, make sure attributes are named correctly as email, first_name, and last_name. If needed, select the checkbox below to automatically apply attribute mapping for your SSO configuration.

You're all set! By following these steps, you've successfully configured SSO for your workspace, providing a seamless and secure login experience for your team. If you have any questions or need further assistance, our support team is always here to help.

Did this answer your question?