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:
Check domain ownership: Make sure the domain is verified before proceeding with any federation setup.
Start small: Use account-specific federation to test and validate your setup in isolation.
Expand safely: Use global federation only if the domain is shared across all relevant accounts or business units.
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:
Choose the right federation model: Use environment-specific federation to isolate SSO configurations.
Allow external access: Configure the scope assignment to allow external users from unverified domains to sign in as account-federated guests via your IdP.
Guide users to the correct entry point: Share the specific environment URL with users so that authentication is routed through the intended identity provider.
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:
Use global federation for a unified setup:
If your organization relies on a single identity provider (IdP) across all accounts and business units, global federation is the best fit. Although each account still requires domain verification, the federation is automatically shared, simplifying consistent user management across environments.
Use account-specific federation for flexibility:
If your organization uses multiple IdPs or has separate user bases (for example, local domains like 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.
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:
Global Federation: If the organization uses a global federation, there's no need to configure a new one.
You only need to verify the domain in the new account—once verified, the existing federation configuration is automatically applied across all environments.
If the migration is within the same Dynatrace account, no changes to the SSO configuration are required—only SAML group permissions need to be updated to include access to the new environment.
Account or Environment Federation: If the migration involves a different Dynatrace account, a new SAML configuration must be created.
This includes setting up a new SAML integration in the IdP and configuring a new federation.
Both the old and new federations can operate in parallel, and authentication will be routed based on the environment context.
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.
All groups are defined and managed at the account level.
SAML groups are dynamically assigned upon login, depending on the federation configuration and identity provider used. As a result, the group membership a user receives can vary based on which federation setup they authenticate through.
SCIM and LOCAL groups are persistently assigned to users and remain unchanged, regardless of which account they initially authenticated into. Since users are global, they can simultaneously belong to groups in multiple accounts.
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:
To restrict access to a specific environment:
Use only SAML groups: Rely on SAML groups from the environment-specific federation to control authorization, and remove or limit any LOCAL or SCIM groups that might grant access to other environments.
Scope group permissions carefully: Whether you're using SAML, SCIM, or LOCAL groups, make sure only the groups intended for the target environment are defined. Review and adjust the permissions assigned to each group accordingly.
Guide users to the correct entry point: Share the specific environment URL with users so that authentication is routed through the intended identity provider.