SSO implementation in Dynatrace depends on your identity architecture and specific organizational needs. This overview presents common setup scenarios to help you evaluate the most suitable approach.
For detailed instructions on setting up SAML integration in Dynatrace with your identity provider, refer to the IdP-specific configuration guides.
Use case: You're setting up SSO for the first time in a new account. Other accounts may not use SSO yet, and there's no centralized identity strategy in place.
Background: There’s no existing federation to connect to, and jumping straight to a global federation could unintentionally affect users in other accounts.
Recommended approach:
Use case: You want to let internal employees and external partners (with different email domains) access the same environment using a single identity provider (IdP).
Background: Using one IdP for multiple domains requires careful setup—especially if you want to avoid verifying external domains.
Recommended approach:
Use case: Your organization manages a large number of Dynatrace SaaS environments across different accounts and aims to implement SSO consistently for internal users.
Background: Setting up SSO across many accounts can be time-consuming and error-prone. Each account might require manual configuration, making it difficult to maintain consistent attribute mappings and access policies.
Recommended approach:
xyz.com, xyz.at), account-specific federation is a better choice. It allows each account to manage its own identity setup independently, offering more flexibility at the cost of additional configuration effort.
You might start with environment-specific federation in a single environment to safely validate the configuration. If everything works as expected, you can expand the setup.When the logged in user belongs to multiple Dynatrace accounts, each configured with account-specific federation, SAML group membership claims are retrieved only for the account the user is currently authenticated in. Accessing an environment in a different account—or switching between environments that each have their own federation—will not carry over those group assignments.
As a result, users may see a 403 You don't have permission to view this page error when navigating to another environment. To resolve this, the user must reauthenticate within that environment's context, which triggers the correct group assignment for that account or environment. Global federation avoids this issue entirely. See Why do I get a 403 You don't have permission to view this page error when switching between accounts or environments with separate federations?.
Use case: Your organization is transitioning from one Dynatrace SaaS environment to another and needs to maintain uninterrupted SSO access during the transition.
Background: During environment migration, it’s important to avoid authentication downtime and ensure that group-based permissions are correctly applied in the new environment.
Recommended approach:
Use case: You want to create a user account with local password authentication (for example, a break-glass user account), but the user's email domain is globally federated, and sign-in is always redirected to the federated IdP.
Background: Global federation intercepts the sign-in flow for all users whose email matches the federated domain. The federation discovery algorithm evaluates global federation before local authentication, so local passwords are never checked for users in a globally federated domain—regardless of how the account was created (UI, API, or SCIM).
Recommended approach:
user@subdomain.federateddomain.com instead of user@federateddomain.com). This is the only way to enable local password sign-in while a global federation is active.Use case: You’ve configured environment-specific federation for a single environment. In your organization, some users authenticate using SSO, while others might rely on password-based credentials. You aim to ensure that all users can be authorized to access the environment, regardless of their authentication method.
Background: Dynatrace users are global, and their authorization is determined through group assignments within each account.
SCIM and LOCAL groups are commonly used to ensure users have the appropriate permissions for an environment. This means that even if federated users aren't added to specific permission groups during login, they might still access the environment due to their SCIM or LOCAL group membership.
Recommended approach: