This guide outlines the essential information IT teams need to configure a Single Sign-On (SSO) connection between an organization’s Identity Provider (IdP) and Vodori.

Please use our form to send details: Vodori Single Sign-On Configuration Request Form

Topics Covered in this article:

• Definitions
• SSO in Vodori
• Supported Native IdPs in Vodori
  • Microsoft Azure AD (OpenID Connect)
  • Okta Workforce (OpenID Connect)
  • Google Workspace (OpenID Connect)
  • PingFederate (SAML)
  • ADFS (SAML)
  • Active Directory / LDAP (via Auth0 Gateway or VPN)
• Custom SSO (Non-Native IdPs)
  • SAML
  • OpenID Connect (OIDC)

Definitions

Vodori is a cloud-based software platform used for the creation, review, approval, and distribution of regulated content. The consolidated platform contains the following apps:

1. Core [Platform] is where claims and promotional and medical content is uploaded, reviewed, and approved.
2. Admin Console is where users with access to Vodori are managed (invited, assigned permissions, revised, deactivated, etc.).
3. Portals are where users retrieve content that has been approved in Vodori.
   1. Note: This app may not be in an organization’s subscription.

Organization is a company that has purchased a subscription to use Vodori’s software. By default, each organization has 2 tenants—one sandbox and one production—each with the Admin Console app and the Core Platform app. 

SSO in Vodori

SSO in Vodori is used solely for authentication. The connection between Vodori and an organization’s Identity Provider (IdP) establishes a secure method for users to sign in using corporate credentials.

Authorization Model

• All authorization is managed within the Vodori Admin Console.
• User administration, access provisioning, and group assignments are managed directly in Vodori.
  • This approach provides transparency into which users have access and the attributes assigned to them, which drive content visibility rules when applicable.
• Group attributes from the IdP are not consumed by Vodori.
• Any groups created in a customer’s IdP (e.g., to track which users are authorized for Vodori) will function only as reference groups for an organization’s internal governance and are not used by Vodori for access control.

  • Note: If you intend to have application-specific IdP groups (e.g., Portals), please confirm with your Vodori business owner which apps are in use.

     

Supported Native IdPs in Vodori

Vodori natively supports the below identity providers using preconfigured enterprise connections. For all connections, please configure your IdP to allow this redirect URI: https://login.vodori.com/login/callback

Important: Your SSO connection will not work unless the Redirect URI above is added to your IdP application configuration.

Vodori does not have access to your Identity Provider (IdP) administration panels.
Because of this, we rely entirely on the information you provide to configure the connection correctly.
If any detail is missing or inaccurate (e.g., redirect URI, certificate, entity ID), the connection may not function as expected.

➡️ So that we can initiate the SSO connection setup for your Vodori instance, please provide the details based on your IdP type.

• If you are in the implementation phase, please provide your Implementation Manager with the required details.
• Existing customers should send all necessary information to ps@vodori.com.
• ❗Reminder: Treat the secret like a password and share via a secure method. If you are unsure how to share the secret securely, please reach out to ps@vodori.com for assistance.

1. Microsoft Azure AD (OpenID Connect)

• Provide the Azure AD details required for Vodori to connect using OpenID Connect (OIDC). These values come from your Azure App Registration.
  • Client ID (Application ID)
  • Client Secret Value (not the client secret ID) from the app's Keys section
  • Comma separated list of email domains to be supported with this connection
• Steps in Azure Portal:
  1. Open portal.azure.com and navigate to Azure Active Directory > App registrations > New application registration
  2. Fill out the application form with a name (such as "Vodori"), select "Web app / API" as the Application type, and insert any valid sign-on URL
  3. Once created, go to the Settings section and choose Keys
  4. Create a new key by inputting a Description and choosing a Duration, then save and copy the App Key (this will only be shown once)
  5. Choose Required permissions and click Add, then select the Microsoft Graph API
  6. Check "Read and write directory data" under Application Permissions
  7. Click "Grant Permissions" and confirm by clicking Yes
  8. If supporting both AD users and personal Microsoft accounts, update the signInAudience flag in the Azure manifest to "AzureADandPersonalMicrosoftAccount"
• If needed, ensure you also configure the Azure AD application with:
  • Proper signInAudience settings in the Azure manifest (set to "AzureADandPersonalMicrosoftAccount" if supporting both AD users and personal Microsoft accounts)
  • Grant permissions for the application
  • Azure AD Domain (e.g., company.com)

2. Okta Workforce (OpenID Connect)

• Provide the required OpenID Connect (OIDC) details from your Okta application. Ensure you assign users or groups appropriate access permissions to Vodori.
  • Okta Org URL (e.g., https://yourcompany.okta.com)
  • Client ID
  • Client Secret
  • Comma separated list of email domains to be supported with this connection (e.g., company.com, agency.com)

3. Google Workspace (OpenID Connect)

• Provide your Google Workspace domain-wide credentials for OIDC authentication.
  • Google Workspace domain (e.g., company.com)
  • Client ID
  • Client Secret
  • Comma separated list of email domains to be supported with this connection (e.g., company.com, agency.com)

4. PingFederate (SAML)

• Provide your SAML metadata or provide the fields manually. Vodori will generate your ACS URL and SP Entity ID based on your Vodori slug.
  • ACS URL convention- https://prod-vodori.us.auth0.com/login/callback?connection=[slug-saml]
  • SP Entity ID - urn:auth0:prod-vodori:[slug-saml]

Provide one of the following:

• Metadata XML file, 
  or
• The following fields manually:
  • Ping Federate Server URL
  • X.509 Certificate (PEM or CER format)
• Optionally, provide a metadata URL if certificate rotation is supported.
• Comma separated list of email domains to be supported with this connection (e.g., company.com, agency.com)

5. ADFS (SAML)

• For ADFS SAML Vodori will generate your ACS URL and SP Entity ID based on your Vodori slug

  • ACS URL convention- https://login.vodori.com/login/callback
  • SP Entity ID - urn:auth0:prod-vodori:[slug-adfs]

  ADFS URL (from your ADFS server)

  Please provide your ADFS Federation Metadata URL (this must come from your on-prem ADFS server, not Microsoft Entra ID).

  Expected format:

  https://<your-adfs-domain>/FederationMetadata/2007-06/FederationMetadata.xml

  Example:

  https://adfs.yourcompany.com/FederationMetadata/2007-06/FederationMetadata.xml

  ⚠️ Important: If your URL contains login.microsoftonline.com, that is Entra ID / Azure AD metadata, not ADFS. Please use either Custom SAML or azure OIDC connection types.

  Please read our guide to determine your slug here.
• Federation metadata URL (preferred) e.g. https://youradfs.domain.com/federationmetadata/2007-06/federationmetadata.xml
• Or the raw metadata XML file
• Comma separated list of email domains to be supported with this connection (e.g., company.com, agency.com)

Important Notes:

• Ensure SAML assertion includes user email (NameID) or email address claim
• Redirect URI should be added in your relying party trust.

6. Active Directory / LDAP (via Auth0 Gateway or VPN)

Note: This method is less common and usually requires a connector or VPN tunnel. If this is your preferred solution, let us know and we will coordinate the setup with our team.

❗Reminder: Treat the secret like a password and share via a secure method. If you are unsure how to share the secret securely, please reach out to ps@vodori.com for assistance.

Custom SSO (Non-Native IdPs)

Vodori also supports:

• Custom SAML connections
• OpenID Connect (OIDC) integrations

Note: Vodori does not generate a metadata XML file for SAML connections where the customer provides the Identity Provider (IdP). Because of this, Vodori does not supply an SP metadata XML file.

We provide all required values (ACS/Reply URL and Entity ID) directly in the setup instructions.

SAML 

Note: Optional SAML settings for customers are listed at the bottom of the page in Appendix A to reduce confusion for most setups.

How to Determine Your Slug

Your slug corresponds to the prefix of your Vodori URL.

• Example: Customer URL: https://customer.vodori.com or https://customer-uk.vodori.com 
• Slug = customer or customer-uk

What Vodori requires for SAML connections vs. what is optional

⚠️ Callout:

SAML Connections require an 'email' claim to be sent in the request.

Vodori does not use IdP groups or attributes for access control. All authorization is managed inside the Vodori Admin Console.

OpenID Connect (OIDC) 

If a discovery document is available, please provide:

• Discovery Document URL - (e.g., https://provider.example.com/.well-known/openid-configuration)

If a discovery document is not available, please provide the following individually:

• Required:

Note: Optional OIDC settings for customers are listed at the bottom of the page in Appendix B to reduce confusion for most setups.

Appendix A: Optional SAML Settings for Customers

Appendix B: Optional OIDC Settings for Customers