---
title: Authentication and roles
description: When a user authenticates, they are given a set of default internal roles. These roles determine how much access the user has to IDM. The default roles can be static roles assigned by definition in authentication.json or dynamic roles assigned by a relationship to the user.
component: pingidm
version: 8.1
page_id: pingidm:auth-guide:authentication-and-roles
canonical_url: https://docs.pingidentity.com/pingidm/8.1/auth-guide/authentication-and-roles.html
keywords: ["Authentication", "Roles", "Security Context"]
section_ids:
  dynamic-role-calculation: Dynamic role calculation
  auth-security-context: Roles, authentication, and the security context
---

# Authentication and roles

When a user authenticates, they are given a set of default *internal roles*. These roles determine how much access the user has to IDM. The default roles can be static roles assigned by definition in `authentication.json` or dynamic roles assigned by a relationship to the user.

You can configure internal roles using the admin UI or the REST API at the `openidm/internal/roles` endpoint.

The following internal roles are defined by default:

* openidm-admin

  IDM administrator role, excluded from the reauthorization required policy definition by default.

* openidm-authorized

  Default role for any user who authenticates with a username and password.

* openidm-cert

  Default role for any user who authenticates with mutual SSL authentication.

  This role applies only to mutual authentication. The shared secret (certificate) must be adequately protected. The `openidm-cert` role is excluded from the reauthorization required policy definition by default.

* openidm-reg

  Assigned to users who access IDM with the default anonymous account.

  The `openidm-reg` role is excluded from the reauthorization required policy definition by default.

* openidm-tasks-manager

  Role for users who can be assigned to workflow tasks.

* platform-provisioning

  Role for platform provisioning access. If you are not planning to run AM and IDM together as a platform, you can safely remove this role.

When a user authenticates, IDM calculates that user's roles as follows:

* Each authentication module includes a `defaultUserRoles` property. Depending on how the user authenticates, IDM assigns the roles listed in that module's `defaultUserRoles` property to the user on authentication. The `defaultUserRoles` property is specified as an array. For most authentication modules, the user obtains the `openidm-authorized` role on authentication. For example:

  ```json
  {
      "name" : "MANAGED_USER",
      "properties" : {
          ...
          "defaultUserRoles" : [
              "internal/role/openidm-authorized"
          ]
      },
      ...
  }
  ```

* The `userRoles` property in an authentication module maps to an attribute (or list of attributes) in a user entry that contains that user's authorization roles. This attribute is usually `authzRoles`, unless you have changed how user roles are stored.

  Any internal roles that are conditionally applied are also calculated and included in the user's `authzRoles` property at this point.

* If the authentication module includes a `groupRoleMapping`, `groupMembership`, or `groupComparison` property, IDM can assign additional roles to the user, depending on the user's group membership on an *external* system. For more information, refer to [Use Groups to Control Access to IDM](../objects-guide/groups-and-access-to-idm.html).

  |   |                                                                                                                                                                                  |
  | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  |   | The roles calculated in sequence are cumulative. Roles with temporal restrictions are not included in that list if the current time is outside of the time assigned to the role. |

## Dynamic role calculation

By default, IDM calculates a user's roles only on authentication. You can configure IDM to recalculate a user's roles dynamically, with each request, instead of only when the user reauthenticates. To enable this feature, set `enableDynamicRoles` to `true` in the `JWT_SESSION` session module in `authentication.json`:

To enable dynamic role calculation through the admin UI, click Configure > Authentication > Session > Enable Dynamic Roles.

Dynamic role calculation can be used independently of the *privileges* mechanism, but is required for privileges to work. For more information about privileges, refer to [How Privileges Restrict Administrative Access](delegated-admin.html#using-privileges).

## Roles, authentication, and the security context

The Security Context (`context.security`), consists of a principal (defined by the `authenticationId` property) and an access control element (defined by the `authorization` property).

If authentication is successful, the authentication framework sets the principal. IDM stores that principal as the `authenticationId`.

The `authorization` property includes an `id`, an array of `roles`, and a `component`, that specifies the resource against which authorization is validated.