Skip to main content

Single Sign-On (SSO)

Updated over a week ago

What is SSO and how does it work?

Single sign-on (SSO) lets users access multiple tools and platforms using one set of login credentials. Instead of managing separate usernames and passwords for each service, users sign in once through a central identity provider and get instant access to everything they’re authorized to use.

When you choose to sign in with SSO, we redirect you to your identity provider’s login page. If you’re not already signed in, you'll be prompted to enter your credentials. Once authenticated, you're redirected back to us with the information we need to grant access. All messages exchanged are signed and can also be encrypted, so the entire process happens over a secure channel.

SSO improves security, reduces password fatigue, and simplifies user management for IT teams.

What types of SSO do we support?

We currently support two types of SSO:

OpenID SSO

OpenID lets you sign in using your existing credentials from a trusted third-party provider. On our platform, you can use OpenID SSO via Google and Microsoft. It’s quick to set up and works well if your organization already manages users through these platforms.

SAML SSO

SAML (Security Assertion Markup Language) is an open standard for exchanging authentication details between a service provider (SP) and an identity provider (IdP). At GWI, we use SAML only to confirm identity. What you can access after signing in is managed within GWI separately.

When you sign in with SAML SSO, we’ll redirect you to your organization’s IdP (for example, Okta, Google, or Microsoft Azure). The IdP verifies your identity and securely passes your basic details back to us. In this setup, GWI acts as the service provider, while your IdP handles verification.

Which one should you use?

Both OpenID and SAML SSO provide a secure, seamless login experience. The best choice depends on your setup:

OpenID SSO (Google or Microsoft)

  • Ideal if your company already manages users through Google Workspace or Microsoft Azure AD.

  • Fast and simple to set up.

  • Minimal IT involvement required.

SAML SSO

  • Ideal if your company needs more customization and control over authentication.

  • Compatible with a wider range of identity providers (Okta, Azure, Google).

  • It requires more configuration, but gives IT teams maximum flexibility. If you’d like to set up this type of SSO for your organization, read below for the configuration steps.

SAML Configuration

To enable the authentication workflow, we need to securely exchange certain details with your identity provider (IdP) in advance. This exchange allows both parties to trust each other—verifying who sent each message and ensuring the message hasn’t been altered.

We use XML metadata files to handle this setup. We need to receive your IdP metadata file, and you'll need ours. Some systems let you provide a secure URL where the metadata can be fetched automatically, while others require you to enter the information manually.

Each metadata file includes your organization's unique ID, a public key (used to verify digital signatures and decrypt messages), and the URLs for specific SAML endpoints.

Below, you'll find detailed setup steps for three of the most common SSO providers. Each section explains how to connect your IdP with our system.

Okta - SAML IdP Provider Setup

This section explains how to configure Okta as your identity provider (IdP) for SAML-based SSO with GWI.

Since Okta requires manual configuration through input forms, we’ll need to share our service provider (SP) metadata with you directly. Follow the steps below to complete the setup:

  1. Set up Okta and send us your metadata URL.
    The metadata URL usually follows this format:
    ​https://<idp-name>.okta.com/app/<app-id>/sso/saml/metadata

    We'd need this URL, along with a list of the email domains you'd like to support.

  2. We register your IdP in our system.

  3. We send you our SP metadata.
    Once your IdP is registered, we’ll provide your SSO administrator with:

    • SP callback URL – to be used as the Single Sign-On URL

    • SP entity ID – to be used as the audience restriction in Okta

    • SP certificate – to verify and encrypt messages

  4. Configure email attribute mapping in Okta.
    Okta must be set to send the user’s email address as an attribute named mail or gwi-mail. This step must be configured manually.

  5. Complete domain linking.
    Once everything is set up, we’ll link your supported email domains to the provider. This tells our system which IdP to use when a user initiates SSO with a specific email address.

Google - SAML IdP Provider Setup

This section explains how to configure Google as your identity provider (IdP) for SAML-based SSO with GWI.

To get started, refer to this Google SAML setup guide for an overview. Then follow the steps below to complete the configuration:

  1. Set up your Google SAML app and send us your metadata URL.
    Once your app is configured, share the metadata URL and the list of email domains you'd like to support.

  2. We register your IdP in our system.

  3. We send you our SP metadata.
    After registration, we’ll provide your SSO administrator with:

    • Entity ID – the SP entity ID

    • ACS URL – labeled as Callback URL in the IdP settings

  4. Configure email attribute mapping in Google.
    Google must be set to send the user’s email address as an attribute named mail or gwi-mail. This must be added manually—it’s not automatic.

  5. Complete domain linking.
    Once setup is complete, we’ll map your supported email domains to this provider. This allows our system to route login requests correctly based on the user’s email address.

Note: Google doesn’t verify SAML requests, so we don’t need to send you a certificate. However, we recommend enabling SAML response signing for additional security.

Azure AD - SAML IdP Provider Setup

This section explains how to configure Azure Active Directory (Azure AD) as your identity provider (IdP) for SAML-based SSO with GWI.

Follow these steps to complete the setup:

  1. Create an application with SAML SSO enabled.
    In your Azure cloud environment, create a new application and enable SAML SSO. This will create the required identity provider. Once complete, share the App Federation Metadata URL from the SAML SSO configuration page with us.

    Important: By default, Azure does not sign SAML responses, which is required for our implementation. To enable this:

    • Go to the SAML Signing Certificate section

    • Click Edit

    • Select Sign SAML response and assertion for the active certificate

  2. We register your IdP in our system.

  3. We send you our SP metadata.
    After your IdP is registered, we’ll provide your SSO administrator with:

    • SP entity ID – shown as Identifier in Azure

    • SP callback URL – shown as Reply URL in Azure

  4. Configure email attribute mapping in Azure.
    You’ll need to manually configure Azure to send the user’s email address as an attribute named mail or gwi-mail. This does not happen by default.

  5. Complete domain linking.
    Once setup is complete, we’ll link your supported email domains to this provider. This allows our system to identify which IdP to use when users sign in via SSO.

Note: Azure does not verify incoming SAML requests, so we don’t need to send you a certificate. Azure will automatically sign SAML responses, and we verify them on our side.

FAQs

What is SAML SSO, and what do we need to know about it?

SAML SSO (Security Assertion Markup Language) is a single sign-on protocol that lets users authenticate once and access multiple applications. It’s commonly used for enterprise-level, domain-based authentication.

Who can I speak to about getting SAML SSO set up?

Reach out to your Account team. If you're not sure who that is, contact GWI Support via Live Chat or by emailing [email protected].

Can we test the SAML SSO integration before enabling it for our entire organization?
No. Once SSO is enabled, all users with the registered email domains will be directed to log in via SSO. There's no way to enable it for just a subset of users for testing

Can some users log in through SAML SSO while others use email and password?
It depends on the email domain. If users share the same domain, they must all use SSO once it's enabled. You can't mix login methods for users with the same registered domain.

What’s the difference between OpenID SSO and SAML (domain-based) SSO?
OpenID SSO uses a third-party provider, like Google or Microsoft, for authentication. Domain-Based SSO, on the other hand, is managed internally by your organization. The key difference is control: Domain-Based SSO gives you full control over the login process, while OpenID SSO is managed externally by the provider.

Why use SAML (domain-based) SSO instead of OpenID SSO?

Domain-Based SSO is often preferred by organizations that need tighter control over authentication. It allows employees to log in using corporate credentials, making it easier to integrate with internal systems like access control, user management, and enterprise apps. OpenID SSO (e.g., Google or Microsoft) relies on personal or third-party accounts, which may not meet an organization’s security or compliance standards.

Did this answer your question?