---
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. IDM includes a number of default internal roles, on the openidm/internal/roles endpoint. You can configure additional internal roles to customize how you restrict access to the server.
component: pingidm
version: 7.2
page_id: pingidm:auth-guide:authentication-and-roles
canonical_url: https://docs.pingidentity.com/pingidm/8.1/auth-guide/authentication-and-roles.html
llms_txt: https://docs.pingidentity.com/pingidm/llms.txt
docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md
superseded_by: https://docs.pingidentity.com/pingidm/8.1/auth-guide/authentication-and-roles.html
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. IDM includes a number of default internal roles, on the `openidm/internal/roles` endpoint. You can configure additional internal roles to customize how you restrict access to the server.

The following internal roles are defined by default (in `conf/repo.init.json`):

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, see [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, see [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.