Single Sign-On (SSO) Integration – Generic SAML Guide

Written by Uday Kumar Updated

Introduction

Single Sign-On (SSO) enables users in your organization to access multiple applications with one set of login credentials. Integrating your enterprise application with a standards-based SSO provider centralizes authentication, improves security, and simplifies user management.

This guide describes the general process for integrating SSO using Security Assertion Markup Language (SAML) with commonly used identity providers, including Microsoft Entra ID (Azure Active Directory), Okta, and OneLogin. It covers the critical steps required by IT administrators and business stakeholders and highlights considerations for back-office AP/AR (Accounts Payable/Receivable) mailbox workflows.

Audience:

  • IT administrators responsible for configuring SSO.
  • Business stakeholders interested in understanding the operational impact.
  • End users who need to know how SSO affects their application login experience.

Prerequisites

Before starting Single Sign-On (SSO) integration, ensure you meet the necessary prerequisites and have coordinated with key stakeholders. Complete the following steps:

  • Confirm organizational requirements: Verify your organization's policies and requirements for identity management and access control.
  • Engage required teams: Coordinate with your internal IT, application administrators, and security teams to align responsibilities and resources.
  • Identify main contacts: Determine who will serve as the technical contact for your application provider and who will manage user provisioning.
  • Notify Auditoria Support: Contact your Auditoria support representative or submit a ticket to support@auditoria.ai to request SSO enablement.

  • Provide Required Information: In your ticket, include:

    • All Auditoria tenant IDs (specify production and/or sandbox).

    • The Auditoria pod region for your tenants (US Standard, US Enterprise, Canada, EMEA).

  • Coordinate with Auditoria: Auditoria must update internal SSO configurations before you proceed.

  • Verify provider compatibility: Ensure your preferred SSO provider (e.g., Microsoft Entra ID, Okta, or OneLogin) supports SAML integration with your application.

Completing these steps will help ensure a smooth and coordinated SSO implementation. If you are unsure about any requirements, reach out to your IT or application support teams before proceeding.

1. Notify Application Support and Gather Required Details

Before you begin configuring SSO, contact your application’s support team to coordinate SSO enablement. This ensures that your provider is informed of your plans and can supply any required tenant- or environment-specific information.

Steps:

  • Submit a support ticket or request to your application provider. Clearly state that you want to enable Single Sign-On (SSO) for your environment.
  • Provide details such as your organization name, tenant or environment IDs (e.g., production, sandbox), and main technical contact information.
  • Request any required SSO parameters, such as a unique connection name, Entity ID, or callback URLs, that must be used during configuration.
  • Confirm with the provider if any approval, backend updates, or pre-configuration are needed before proceeding.

Having these details prepared in advance helps prevent configuration delays and ensures a coordinated SSO deployment. If your provider has a dedicated SSO onboarding process or checklist, use it to make sure all requirements are met.

2. Create an Application in Your SSO Provider’s Console

Create a new SAML application in your selected Single Sign-On (SSO) provider’s administrator console. This application serves as the integration point between your identity provider and your enterprise application.

Steps:

  • Sign in to your SSO provider’s administrator portal (for example, Microsoft Entra ID, Okta, or OneLogin).
  • Create a new SAML application or connector. Use a clear, descriptive name that reflects your enterprise application or its environment.
  • Follow your provider's standard process to begin configuration.

For provider-specific setup instructions, refer to:

Once completed, your SSO provider will be ready to connect with your enterprise application through SAML integration.

3. Configure SAML Single Sign-On (SSO)

Set up SAML as the authentication protocol in your SSO provider’s console and enter the required configuration details to connect your identity provider with your enterprise application. You will typically need the Entity ID, Reply URL (Assertion Consumer Service URL), Single Logout (SLO) URL, and certificate information, all provided by your application support team.

Steps:

  • In your SSO provider’s admin console, choose SAML as the single sign-on method for your application.
  • Enter the Entity ID, Reply URL, and SLO URL values supplied by your application provider.
  • Upload or configure the SAML signing certificate, if required.
  • Adjust any advanced options, such as signature algorithms, as directed by your application or provider documentation.
  • Save your changes.

For detailed, provider-specific setup instructions, see:

This step ensures that your SSO provider is configured to securely exchange authentication data with your enterprise application.

4. Enter Basic SAML Configuration Details

On the SAML configuration page of your SSO provider, enter the details that link your identity provider to your Auditoria tenant. These values must match the region (pod) where your Auditoria tenant is hosted.

To enter basic SAML configuration:

  1. Under the Basic SAML Configuration section, select Edit.
  2. Enter the following details using the values for your Auditoria pod region. Replace <<conn-name>> with the value provided by your Auditoria Customer Success contact.

For each field, use the following values:

  • Identifier (Entity ID):
    • US Standard: urn:auth0:prod-auditoria:<<conn-name>>
    • US Enterprise: urn:auth0:prod-auditoria-ent1:<<conn-name>>
    • Canada: urn:auth0:prod-auditoria-ca:<<conn-name>>
    • EMEA: urn:auth0:prod-auditoria-em1:<<conn-name>>
  • Reply URL (Assertion Consumer Service URL):
    • US Standard: https://auth.auditoria.ai/login/callback?connection=<<conn-name>>
    • US Enterprise: https://auth-ent1.auditoria.ai/login/callback?connection=<<conn-name>>
    • Canada: https://auth.auditoria.ca/login/callback?connection=<<conn-name>>
    • EMEA: https://auth-em1.auditoria.ai/login/callback?connection=<<conn-name>>
  • SLO URL (Single Logout URL):
    • US Standard: https://auth.auditoria.ai/logout
    • US Enterprise: https://auth-ent1.auditoria.ai/logout
    • Canada: https://auth.auditoria.ca/logout
    • EMEA: https://auth-em1.auditoria.ai/logout
  • Sign on URL and Relay State are optional and can be left blank unless otherwise directed.

3. Select Save to apply your changes.

Note: If you are unsure of your Auditoria pod region or have not received your <<conn-name>> value, contact your Auditoria Customer Success team. Using the correct values is required for a successful SSO connection.

5. Map User Attributes and Claims

Configure user attributes and claims in your SSO provider to ensure that your enterprise application accurately identifies authenticated users. Most SaaS applications require the user’s email address to be included in the SAML response.

Steps:

  • In your SSO provider’s application configuration, locate the section for attributes and claims (sometimes called attribute mapping or claim mapping).
  • Set the NameID or Unique Identifier to use the user’s email address. This is often labeled as user.mail, user.email, or userPrincipalName, depending on the provider.
  • Map any additional claims required by your application (for example, display name, group membership, or roles) as specified in your application’s documentation.
  • Save your changes.

Correctly mapping user attributes ensures that your application's user accounts match the information provided by SSO, enabling seamless, secure sign-in experiences. If you are unsure which attributes to map, consult your application support team or the provider’s integration documentation.

6. Download and Share SAML Metadata/Certificate

After completing your SAML configuration, download the signing certificate or metadata file from your SSO provider’s administrative console. This information enables secure communication between your identity provider and your enterprise application.

Steps:

  • In your SSO provider’s application settings, locate the section labeled SAML Signing Certificate or SAML Metadata.
  • Download the certificate (typically in Base64 .cer or .pem format) and, if available, the SAML metadata XML file.
  • Save these files securely.
  • Send the certificate and any necessary metadata or SSO URLs (such as the Login URL and Logout URL) to your application provider using their specified method (for example, via a support ticket or an upload portal).

Providing the correct certificate and metadata ensures safe and reliable SSO integration between your application and identity provider.

7. Complete Application-side SSO Configuration

After you have provided all required SSO details—such as the SAML certificate, metadata, and key URLs—to your application provider, confirm that the backend SSO setup is complete on the application side.

Steps:

  • Verify with your application provider or support contact that they have received all necessary SSO information.
  • Ensure the provider has updated their backend configuration and applied the SSO settings for your environment or tenant.
  • Wait for written confirmation or a notification from the application provider that SSO setup is complete and ready for user testing.
  • Do not proceed with enabling SSO for end users until confirmation is received.

Completing this step ensures that both the identity provider and the enterprise application are correctly configured and can communicate securely for user authentication.

8. Assign Users and Groups to the SSO Application

Once the SSO configuration is complete and confirmed by your application provider, assign the necessary users, groups, or roles to the SSO application in your identity provider’s console. This step enables users to access the enterprise application through SSO.

Steps:

  • In your SSO provider’s admin console, find and select the configured SSO application.
  • Assign users, groups, or roles that require access to the enterprise application.
  • Save your changes.

Only users and groups assigned to the application will be able to authenticate and access it via single sign-on. Review and update assignments regularly to maintain secure access control. 

Certificate Handling, Expiry, and Renewal

SAML Single Sign-On relies on a signing certificate in your identity provider (IdP) to sign authentication assertions. This certificate has an expiration date and must be monitored, renewed, and rotated to avoid SSO outages.

Monitor Certificate Expiration

  • In your SSO provider’s admin console, locate the SAML Signing Certificate (or equivalent) for your SSO application.

  • Note the expiration date of the active certificate.

  • Record this date in your organization’s change or calendar system and set reminders at least 30–60 days before expiry.

Prepare the New Certificate in Your SSO Provider

When you are ready to rotate the certificate:

  1. In your SSO provider (for example, Microsoft Entra ID, Okta, OneLogin, Shibboleth, or PingFederate), open the SSO application used for your enterprise application.

  2. Generate or add a new SAML signing certificate for that application.

  3. Do not delete or deactivate the existing certificate yet. Keep the current certificate active until your application provider confirms that the new certificate has been configured and tested successfully.

Download and Share the Updated Certificate/Metadata

  1. From your SSO provider’s SAML configuration for the application, download:

    • The new SAML signing certificate (for example, Base64 .cer/.pem or X.509 format), and

    • If available, the updated SAML metadata XML file.

  2. Send the following information to your application provider (for example, Auditoria) using their specified channel (such as a support ticket or onboarding form):

    • The new SAML signing certificate file.

    • Any updated SSO endpoints (for example, Login URL, Logout URL, and Issuer/Entity ID), if they have changed.

    • The tenant and environment identifiers the change applies to (for example, production or sandbox, and the relevant Auditoria pod region).

Coordinate a Change Window

To minimize user impact:

  1. Schedule a short maintenance window that includes:

    • Your SSO/identity provider administrator, and

    • One or more test users.

  2. During this window, your application provider will:

    • Update their SSO configuration to trust the new certificate, and

    • Ask your test users to sign in via SSO to confirm successful authentication.

Avoid making the new certificate the only active certificate in your identity provider before the application-side update and testing are complete.

Validate and Complete the Rotation

  1. Have test users access the enterprise application via SSO (for example, by launching it from the SSO provider’s app portal).

  2. Confirm the following:

    • Users can sign in successfully without errors.

    • User identity and access (roles, permissions) are correct.

  3. After successful validation and confirmation from your application provider:

    • Remove or deactivate the old SAML signing certificate in your SSO application, following your internal security and change-management policies.

If SSO Fails After a Certificate Change

If users cannot sign in after a certificate rotation:

  1. Check your SSO provider configuration:

    • Confirm that the correct new certificate is active for the SSO application.

    • Verify that the Entity ID, Reply URL (ACS URL), and Logout URL (SLO URL) have not been changed incorrectly.

  2. Engage your application provider:

    • Inform them that a SAML signing certificate rotation was recently performed.

    • Provide the exact certificate file and any updated metadata you are using.

  3. Use rollback if possible:

    • If the previous certificate is still available and not yet expired, work with your application provider and SSO admin to temporarily revert to the previous certificate while you re-export and validate the new one.

Provider-Specific Notes (Auditoria SSO)

For Auditoria SSO integrations, the lifecycle and renewal process is the same across all supported identity providers, with minor differences in file format and UI:

  • Microsoft Entra ID (Azure)

    • Use the SAML Signing Certificate shown for the enterprise application.

    • Download it in Base 64 format and send it to Auditoria along with the Login URL, Identifier, and Logout URL.

  • Okta

    • Download the .pem certificate from the Okta SAML application and share it with Auditoria, as described in your internal Okta SSO guide.

    • Okta configurations may also require uploading a certificate provided by Auditoria for Single Logout (SLO) calls from the service provider side.

  • OneLogin

    • From the SSO tab of the OneLogin application, download the X.509 certificate and provide it to Auditoria so it can be configured in the SAML connection.

Regardless of provider, the key actions are the same: monitor the certificate’s expiry, generate and download a new signing certificate, share it with Auditoria, coordinate a change window, test SSO, and then retire the old certificate.

Support and Troubleshooting

If you encounter issues during or after SSO implementation, use the following steps:

  • Review official documentation from your SSO provider and your enterprise application for troubleshooting guidance.
  • Check your configuration settings for common errors, such as incorrect URLs, certificate mismatches, or user assignment issues.
  • If problems persist, contact your enterprise application’s support team and provide detailed information, including screenshots, error messages, and configuration details.
  • Open a support ticket with your SSO provider if the issue appears related to identity management or authentication.
  • For internal issues, involve your IT support team for assistance with local networking, directory services, or access management.

Consulting the correct resources and providing clear details will help resolve SSO issues efficiently and restore access for your users.