Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Users

Single Sign On - Customer FAQ

search

Please Note:

Single Sign On - Customer FAQ

Table of Contents

What is SSO?

What is Single Sign-On (SSO) for DPoD?

Single Sign-On (SSO) allows your users to authenticate to the DPoD platform using your organization's Identity Provider (IDP) instead of a DPoD username and password. This means users can access DPoD using the same corporate credentials they use for other enterprise applications.

What authentication methods does DPoD support for SSO?

DPoD currently supports SSO federation via OpenID Connect (OIDC). Additional integration types may be validated on a request basis. Please contact support if you require a different integration method.

What are the benefits of enabling SSO?

  • Centralized authentication - Users authenticate through your organization's IDP
  • Simplified access management - Manage user access through your existing identity platform
  • Consistent security policies - Enforce your organization's authentication and MFA policies
  • Reduced password fatigue - Users don't need to remember separate DPoD credentials

Getting Started

Who can request SSO for their DPoD account?

To request SSO, you must meet the following requirements:

  1. You must be a tenant administrator on at least one DPoD tenant
  2. Your email address must be in the same domain you're requesting SSO for (e.g., if requesting SSO for company.com, your email must be user@company.com)
  3. You must have consent from all tenant administrators whose users will be impacted by this change

How do I request SSO?

Submit a support ticket through the Thales Support Portal. Our Client Services team will guide you through the process and provide you with all necessary information.

Is there a cost for enabling SSO?

SSO configuration for accounts with a valid subscription follows our standard support process. For trial and development accounts, approval from Product Line Management may be required.

Requirements and Eligibility

What information do I need to provide?

To begin the SSO setup process, you'll need to provide:

  1. Email domain - The domain you want to enable SSO for (e.g., company.com)
  2. External IDP provider - Which Identity Provider you'll be using (e.g., Microsoft Entra ID, Okta, Ping Identity, Google Workspace, etc.)
  3. ACR values (optional) - Any Authentication Context Class Reference values you want enforced during SSO authentication

What technical details will I need during setup?

During the configuration phase, you'll need to provide the following OIDC configuration details through a secure deposit box:

  • Email domain - The domain to enable SSO for
  • Well-known endpoint - Your IDP's OpenID Connect discovery URL
  • Client ID - The OIDC Client ID (for Microsoft Entra ID, this is the Application ID)
  • Client Secret - The OIDC Client Secret
  • Email claim name - The name of the claim in the ID token containing the user's email address (e.g., email, preferred_username, upn)
  • Initial test user email - Email address of a user for initial testing
  • ACR values (optional) - Any specific authentication context requirements

What are ACR values and do I need them?

Authentication Context Class Reference (ACR) values can be used to request a specific authentication context from your IDP. For example, you might use ACR values to enforce multi-factor authentication or a particular authentication method at the OIDC protocol level. If you're unsure or don't require specific ACR values, you can leave this blank.

Impact and Changes

Warning

Before enabling SSO please understand the following critical points listed below.

SSO is a Global Setting

  • SSO applies to all users with your email domain across all DPoD tenants
  • It is not possible to enable SSO for only a subset of users or specific tenants within the same domain
  • For example, if you enable SSO for company.com, it affects all users with @company.com email addresses across all your tenants

Only One IDP Per Domain

  • A single external IDP can be configured per email domain
  • Subdomains are treated separately (e.g., dept.company.com is separate from company.com)

Existing Login Methods Will Be Removed

  • Once SSO is fully enabled, all existing users in your domain will no longer be able to log in using their DPoD username/password or passkey
  • They will be required to authenticate via your organization's IDP
  • This change is permanent for SSO users

New Users Default to SSO

  • Any new users created with your email domain will automatically be configured as SSO users

How many users will be affected when I enable SSO?

When you submit your SSO request, our team will analyze your account and provide you with the exact number of: - Tenants that will be impacted - Users that will be migrated to SSO

You'll receive this information before proceeding with the configuration.

What happens to users with different email domains?

Users with email addresses outside of your configured SSO domain (e.g., personal gmail.com addresses, contractors with different corporate domains) are not affected by SSO migration. These users will continue to use local DPoD authentication.

Best Practice: We recommend reviewing your user lists after SSO is enabled to ensure only authorized users have access and remove any external email addresses if this is undesirable.

Will SSO affect service accounts or API credentials?

No. Service accounts and API credentials are not converted to SSO and will continue to function as before with their existing authentication methods.

The SSO Setup Process

What is the overall process for setting up SSO?

The SSO setup follows these steps:

  1. Submit Request - Create a support ticket via the Thales Support Portal
  2. Initial Review - Client Services provides an overview and validates your eligibility
  3. Information Gathering - You provide your email domain, IDP details, and ACR values (if any)
  4. Impact Assessment - Our team analyzes and reports how many tenants/users will be affected
  5. Secure Configuration Exchange - You upload your IDP configuration details via a secure CryptoBox deposit box
  6. Initial Test Setup - We configure SSO for one test user in "hybrid mode" (both SSO and existing credentials work)
  7. Testing - You test SSO login with the initial user
  8. Full Migration - After confirmation, we migrate all remaining users to SSO
  9. Validation - You confirm all users can access DPoD via SSO
  10. Completion - Request closed, SSO is fully active

How long does the SSO setup take?

The timeline varies depending on: - How quickly you can provide the required information - Testing phase duration - Your preferred go-live date

Typically, once all information is provided, the initial test user can be configured within a few business days. The full migration happens after you've successfully tested and approved the configuration.

What is "hybrid mode" for testing?

During the testing phase, the initial test user is configured in "hybrid mode," which means they can log in using both: - SSO via your external IDP (new method) - Their existing DPoD username and password (old method)

This allows you to verify that SSO is working correctly before committing to the full migration.

What happens during the full migration?

Once you confirm that testing is successful:

  1. All users with your email domain are converted to SSO-only authentication
  2. Their existing DPoD passwords, MFA settings, and passkeys are permanently removed
  3. Users receive an automated email notification that their account has been converted to SSO
  4. The initial test user is also converted from hybrid mode to SSO-only

How will my users know their accounts have been changed?

All users will receive an automated email from the DPoD platform notifying them that their account has been converted to SSO authentication.

Technical Requirements

What Identity Providers are supported?

DPoD supports SSO federation via OIDC, which is compatible with most modern Identity Providers, including: - Microsoft Entra ID (Azure AD) - Okta - Ping Identity - Google Workspace - Other OIDC-compliant providers

If you're using a different IDP, please contact support to validate compatibility.

How do I securely share my IDP credentials?

Your IDP configuration contains sensitive credentials (client secrets). Thales uses CryptoBox, a secure file exchange system, to protect this information.

Our support team will provide you with: - A unique deposit box URL - An access code

You'll upload your completed configuration to this secure deposit box. The deposit box is single-use only for maximum security.

What if I need to update my configuration after uploading?

The deposit box is single-use and becomes unavailable after you upload your file. If you need to provide different information or if the upload fails, contact our support team and we'll request a new deposit box link for you.

Do I need to configure anything in my IDP?

Yes. You'll need to configure your IDP to allow OIDC authentication for DPoD. Specific requirements vary by IDP provider, but generally include:

  • Registering DPoD as an application/client in your IDP
  • Configuring redirect/callback URLs (provided by Thales support)
  • Ensuring the ID token includes an email claim
  • Generating a client ID and client secret

Our support team can provide guidance specific to your IDP during the setup process.

Security and Best Practices

Does DPoD require Multi-Factor Authentication (MFA) for SSO users?

While DPoD does not enforce MFA at the platform level for SSO users, Thales strongly recommends enforcing Multi-Factor Authentication (MFA) at your external IDP level. This ensures your users' accounts remain secure.

What happens if my IDP is unavailable?

Important: Thales cannot provide availability guarantees for user authentication via an external IDP.

SSO authentication availability is dependent on your organization's Identity Provider and is not covered under the DPoD Service Level Agreement (SLA). The DPoD SLA applies to the platform's availability and performance, but does not extend to third-party authentication services.

If your organization's IDP is unavailable, your users will not be able to log in to DPoD until the IDP is restored. For this reason, we recommend:

  • Ensuring your IDP has appropriate high-availability configurations
  • Having contingency plans for IDP outages
  • Maintaining at least one non-SSO administrator account (using a different email domain) for emergency access
  • Reviewing your organization's IDP SLA to understand authentication availability commitments

Can I keep one administrator account that doesn't use SSO?

Yes. This is actually a recommended best practice. Consider maintaining at least one administrator account with an email address from a different domain (e.g., a personal email or alternative corporate domain) that will continue using local DPoD authentication. This provides emergency access if your IDP experiences issues.

Special Cases

What about subdomains?

SSO configuration does not cascade to subdomains. Each subdomain is treated as a separate email domain:

  • company.com is separate from dept.company.com
  • You can configure different IDP settings for each subdomain if needed
  • You would need to submit separate SSO requests for each subdomain

Can I use different IDPs for different email domains?

Yes. Each email domain can be configured with its own IDP. However, only one IDP can be configured per email domain.

What if I have users across multiple tenants?

SSO is a global setting that applies to all tenants where users with your email domain exist. During the impact assessment phase, our team will provide you with the exact number of tenants that will be affected.

What about users who are invited to multiple tenants?

If a user with your SSO-enabled email domain has access to multiple tenants (whether owned by your organization or others), they will use SSO to log in regardless of which tenant they're accessing.

Managing SSO

Can I disable SSO after it's been enabled?

Yes. A tenant administrator can request that SSO be disabled by submitting a support ticket.

Important: If SSO is disabled: - All user accounts in the domain are reverted to local authentication - Users must register with a new password and MFA on the platform - Previously configured SSO credentials and settings are removed

How do I add new users after SSO is enabled?

Simply add users as you normally would through the DPoD platform. Any new users created with your SSO-enabled email domain will automatically be configured as SSO users.

Can I change my IDP after SSO is configured?

Yes. Submit a support ticket requesting an IDP change. The process will be similar to the initial setup, and may require a migration of existing users.

Support and Troubleshooting

Where do I get help with SSO setup?

Submit a support ticket through the Thales Support Portal. Our Client Services team will guide you through the entire process.

What if SSO login isn't working during the testing phase?

If you encounter issues during testing, check the following:

  • Enter your email domain in lowercase - There is a known issue where the domain portion of the email must be entered in all lowercase letters during SSO login (e.g., use user@company.com not user@Company.com)
  • Ensure the test user's email address in your IDP exactly matches the email address registered in DPoD
  • Verify that the email claim/attribute in your IDP is correctly configured
  • Check that your IDP has the correct redirect/callback URLs configured
  • Verify that the OIDC client ID and secret are correct

If issues persist, reply to your support ticket with details of the error and our team will investigate.

What if users can't log in after the full migration?

Common troubleshooting steps:

  1. Enter email domain in lowercase - There is a known issue where the domain portion of the email must be entered in all lowercase letters during SSO login (e.g., use user@company.com not user@Company.com)
  2. Verify the user exists in your IDP - The email address in your IDP must match the DPoD account exactly
  3. Check IDP availability - Ensure your organization's IDP is operational
  4. Review IDP configuration - Verify that the OIDC application settings haven't changed
  5. Contact support - If issues persist, contact Thales support with specific error messages or screenshots

Who do I contact for ongoing SSO support?

For any SSO-related issues or questions after setup is complete, submit a ticket through the Thales Support Portal.

On this page