Identity and Access Management concepts

Review the following to help you understand key concepts of Dynatrace SaaS Identity and Access Management (IAM).

Identity management

There are two types of identities within Dynatrace SaaS IAM: users and service users.

Users

Users in Dynatrace SaaS IAM are global entities uniquely identified through their email addresses. They can be invited into one or more Dynatrace accounts and can be non-federated (local) or federated.

Use cases

For more information, see User management.

Service users

Service users are non-human identities that are meant to be used by applications, services, or automated processes to interact with other services and resources. In this respect, they are useful for machine-to-machine communications.

Use cases

For more information, see Service users.

Identity federation

Identity federation is a process that allows users to access multiple systems or applications using a single set of credentials, typically managed by an external identity provider (IdP). This approach enables Single Sign-On (SSO) across different domains and organizations, enhancing user convenience and security.

Use cases

Dynatrace SaaS supports SAML integration to allow you to delegate authentication requests to your enterprise IdP.

The following flow diagram captures how authentication requests from federated and non-federated users are routed.

Admins can configure SAML integration at three levels:

Note that configuring identity federation requires that you verify the ownership of your domain to avoid any misuse.

Dynatrace SSO services implement the following Federation Configuration Discovery flow to determine which configuration would apply for a given user.

For more information, see SAML, SCIM, and Sign in with Microsoft in Dynatrace SaaS SSO.

Access management

Access control approaches

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

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.

There are various group types, depending on the source that triggered the group creation. The group type also determines how group membership is handled.

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 many 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";

Unlike roles, which are finite in numbers and with predetermined permissions, policies give you an empty canvas where you can combine user, resource, and contextual attributes to implement any business-specific access permissions applicable to you. However, because of such high flexibility and granularity, they can be overwhelming at first.

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.

Use cases

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

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"

A policy boundary can be applied to multiple group-to-policy bindings, and a group-to-policy binding can have none, one, or multiple policy boundaries applied to it.

This makes policy boundaries a very scalable component of the Dynatrace ABAC framework and also potentially a useful mechanism to simplify your ABAC permissions setup.

Policy boundaries are particularly useful when you decide to leverage default policies. In this scenario, since default policies are read-only, policy boundaries provide a good mechanism for defining your additional business-specific access permissions.

Another scenario where you might make use of policy boundaries is when certain WHERE condition repeats across many of your custom policies. In such a case, you may consider moving that condition over to a policy boundary, which you can then apply selectively to group-to-policy bindings involving the said policies. 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.

Use cases

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.

As it is obvious from 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 the security context, see Grant access to entities with security context.

Roles

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

In Dynatrace, roles cover three different levels:

When a role granted to a group is scoped at the management zone level, it effectively turns that management zone into a security filter for the users of that group.

The actual permissions included in a particular role, as well as the individual resources targeted, are designed and managed by Dynatrace. Furthermore, 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.

IAM tokens

Dynatrace SaaS Token Service is the component responsible for issuing, validating, and managing the lifecycle of issued tokens. These include tokens that are automatically exchanged in the background with web clients upon successful user logins or other tokens, such as OAuth tokens, platform tokens, and tokens exchanged for service user access.

Use cases

The following token types are issued by the token service relevant to IAM.

For more information, see API tokens and OAuth clients.