Access management concepts

• Concept
• 6min
• Updated on Jun 18, 2025

Access control approaches

Dynatrace SaaS supports permission management through Attribute-Based Access Control (ABAC) and Role-Based Access Control (RBAC).

For a comparison of RBAC and ABAC, and guidelines for upgrading from RBAC to ABAC, see Upgrade role-based permissions to Dynatrace IAM policies.

Groups

Groups represent a collection of platform identities that share common access requirements. Groups in Dynatrace IAM exist within the context of a Dynatrace account.

SAML groups

To enable SAML groups, first set up a valid SAML integration that includes group claims within the SAML federation group attributes. When a federated user logs in, the system scans the SAML payload assertions for group claims and checks for matching Dynatrace SAML Group Attribute Values. If a match is found, the user is automatically granted group membership. This setup allows SAML integration to function as an authorization mechanism, enabling administrators to manage Dynatrace access within their enterprise identity provider (IdP).

For more information, see Group management.

Policies

Policies are a key component of the Attribute-Based Access Control (ABAC) that encapsulate a set of permissions against protected platform resources and data. They leverage user, resource, data, and contextual attribution to enable you to configure access to your Dynatrace secure resources. You can secure individual data resources, apps, and services while optionally specifying business-specific access control conditions through the expressiveness of the policy statements syntax. A policy consists of one or more policy statements that can be assigned to one or more groups, effectively granting the users of those groups the resource access defined by that policy.

Use cases

For example, the Dynatrace ABAC policy below defines the permission to install or delete (action) custom apps (resource) where (condition) app identifier (resource attribute) is prefixed with "custom" (attribute value):

ALLOW app-engine:apps:install, app-engine:apps:delete WHERE shared:app-id startsWith "custom";

Policies also offer high granularity when accessing data. For example, the policy statement below effectively defines a permission at the record level by allowing access to only log records that are tagged with "TeamA" in the security context field:

ALLOW storage:logs:read WHERE storage:dt.security_context="TeamA";

Policies are granular and flexible and offer full flexibility to define access based on users, resources, and context. it supports implementing any business-specific access permission. To give you a quick start into ABAC, Dynatrace provides a set of carefully crafted default policies that already encapsulate typical Dynatrace access use cases. These can be used as is or in combination with other custom policies or policy boundaries. For more information, see Working with policies.

Policy boundaries

Policy boundaries are an optional but useful component of the Dynatrace ABAC framework. They are intended for use in conjunction with group-to-policy bindings to further limit group permissions defined in the given policies. An easy way to think about boundaries is to consider them as a stand-alone component that allows you to define your business-specific access control requirements.

A policy boundary can be applied to multiple group-to-policy bindings. A group-to-policy binding can have zero, one, or multiple policy boundaries applied to it. This makes policy boundaries a scalable component of the Dynatrace ABAC framework and also mechanism to simplify your ABAC permissions setup.

Use cases

For example, you can create a boundary that defines working hours using the global attribute time-of-day:

global:time-of-day > "09:00+01:00";
global:time-of-day < "17:00+01:00";

If you apply this boundary to the following policy and bind the policy to a group, you are effectively restricting users of that group access to the specified app only during specified hours of the day.

ALLOW app-engine:apps:run WHERE shared:app-id = "dynatrace.automations"

Policy boundaries are useful when you decide to leverage default policies. In this scenario, since default policies are read-only, policy boundaries provide a mechanism for defining your additional business-specific access permissions. Another scenario to use policy boundaries is when a certain WHERE condition repeats across many of your custom policies. In such a case, you can move that condition over to a policy boundary. Then, apply the policies selectively to group-to-policy bindings. Note that you can continue to use WHERE conditions in a custom policy even if you apply a boundary to it. For more information, see Policy boundaries.

Policy templates

Policy templating allows for the creation of reusable policies that implement parameterized values in their WHERE condition.

For example, consider the following policies:

//Pol_TeamA
ALLOW storage:logs:read WHERE storage:dt.security_context = "TeamA";

//Pol_TeamB
ALLOW storage:logs:read WHERE storage:dt.security_context = "TeamB";

//Pol_TeamC
ALLOW storage:logs:read WHERE storage:dt.security_context = "TeamC";

These policies can instead be replaced with one policy:

//Pol_AllTeams
ALLOW storage:logs:read WHERE storage:dt.security_context = "${bindParam:team}";

When the above policy is bound to groups Grp_TeamA, Grp_TeamB, Grp_TeamC, it is possible to specify ${bindParam:team} value for each binding, respectively to TeamA, TeamB and TeamC. In the example above, you can greatly reduce your custom policy footprint, if policy templating is applicable to your specific access control requirements. For another example of using security context, see Grant access to entities with security context.

Roles

Roles represent a key component of the Role-Based Access Control (RBAC). It encapsulate a set of permissions that target protected platform resources and data. When roles are assigned to groups, they allow members of those groups access to secured resources. In Dynatrace, roles cover three different levels:

When a role granted to a group is scoped at the management zone level, the management zone becomes a security filter for the users of that group. The permissions included in a role, as well as the individual resources targeted, are designed and managed by Dynatrace. To keep the roles to a manageable number, only a limited number of roles are made available. Due to these and other RBAC limitations, we recommend using ABAC to configure your Dynatrace permissions. For a comparison of RBAC and ABAC, and guidelines for upgrading from RBAC to ABAC, see Upgrade role-based permissions to Dynatrace IAM policies.

Access management - putting it all together

The following high-level diagram captures the relationship among the above components that determine access control decisions by the Dynatrace IAM framework.

The following diagram drills down a bit deeper into the key concepts of the ABAC framework.