How To
ForgeRock Identity Platform
Does not apply to Identity Cloud

How do I understand what privileges apply to amAdmin and delegated administrators in AM (All versions)?

Last updated Jan 16, 2023

The purpose of this article is to provide comparison information on the difference between the administrative privileges assigned to amAdmin and those of delegated administrators, and which administrative tasks require amAdmin (Super user) access rights. Some aspects of amAdmin functionality are hard-coded and therefore only apply to the amAdmin user.


You can create other admin users with similar privileges to the amAdmin user by delegating administration but you should be aware that these users will not function in exactly the same way as the amAdmin user. Some aspects of the amAdmin functionality is hard-coded and therefore only applies to the amAdmin user. From The amAdmin user:

The amAdmin account cannot be deleted since it is hard-coded in the source code of several files.

This article looks at the capabilities of amAdmin and delegated administrators in more detail, and covers:

Delegated privileges

You can delegate tasks based on privileges. See How do I add privileges to identity groups in AM (All versions)? and Delegate privileges for details on how you assign privileges and what privileges you can assign.

The following diagram illustrates the scope of control by administrator users at different levels; this is discussed in more detail below:

Top level realm

If you create an administrator user in the top level realm with all the privileges listed in Delegate privileges, they will have full control over the configuration and services of the top level realm, including the ability to add and update sub-realms. Such an administrator user is operationally equivalent to the amAdmin user.

See the amAdmin only tasks section below for details on the limitations of a top level realm administrator compared to the amAdmin user.


If you create an administrator user in a sub-realm (child realm) with all the privileges listed in Delegate privileges, they will be able to add services and alter the configuration of the sub-realm to which they belong and any sub-realms beneath that level. They will not be able to do anything at a Server instance or global level.

A sub-realm administrator cannot perform the following tasks:

  • Alter Global service configuration defaults that impact all realms.
  • Configure the following details for a Server instance:
    • File system installation locations.
    • Site and load balancing information.
    • Logging locations.
    • Keystore configuration.
    • Encryption and Certificate Revocation.
    • Core Token Service configuration.
    • User-Managed Access storage configuration.
    • Advanced parameters, instance and debug configuration.

amAdmin only tasks

The following tasks can only be performed by the amAdmin user:

  • Changing the amAdmin user's password. See The amAdmin user for further information.
  • Recording troubleshooting information via REST. See How do I record troubleshooting information in AM (All versions)? for further information.
  • Logging in to a server once the maximum number of sessions has been exceeded. However, the amAdmin user cannot log in to a realm if client-side sessions are configured (but a delegated administrator can).
  • Using the following directory JSP endpoints, which are detailed in JSP files:
    • Logback.jsp (AM 7 and later)
    • Debug.jsp (AM 6.x)
    • encode.jsp
    • getServerInfo.jsp
    • showServerConfig.jsp
    • services.jsp
  • Triggering the following workflow tasks accessed from the realm level Common Tasks page (AM 6.x) - these workflows are triggered by the AjaxProxy.jsp endpoint, which is detailed in Console Ajax JSP files. Only the amAdmin user has access to this endpoint:
    • Configure SAMLv2 Provider
    • Configure OAuth Provider
    • Create Fedlet Configuration
    • Configure Google Apps
    • Configure Salesforce CRM
    • Configure Social Authentication

Delegated administrators can manually configure the providers, services and SAML entities configured via these workflow tasks; automation is also possible for delegated users via ssoadm and REST (where REST is available).

  • Configuring SOAP and REST via the AM admin UI (delegated administrators can configure these via ssoadm). Again, these configuration pages rely on the AjaxProxy.jsp endpoint, which is only accessible to the amAdmin user.

Performance considerations

The amAdmin user is likely to have faster response times when compared to a user with delegated administrative privileges. This is because delegation policies explicitly check to see if the current user is the amAdmin user:

  • If they are, it is assumed that all operations are permitted.
  • If they aren't, additional checks are performed to see if the group they belong to has been delegated the correct privilege.

Upgrade considerations

Upgrade processing does not typically require use of the amAdmin account; however, it does require file system access to the web container in which AM is running.

See Also

How do I add privileges to identity groups in AM (All versions)?

FAQ: Users in AM

Administrator and user accounts in AM

Delegate privileges

Related Training


Related Issue Tracker IDs

OPENAM-13339 (Custom Admin can't view SAML or configuration tab)

OPENAM-10976 (Provide a fully delegated non-amAdmin account in the top level realm for use with the Record endpoint)

OPENAM-10912 (Describe permissions required to use each REST endpoint in API Explorer)

OPENAM-10860 (refactor checks for superUser to make it easier to analyse where it is required)

OPENAM-10802 (bugs caused by hard coded amadmin check in admincheck.jsp and AjaxProxy.jsp)

OPENAM-4034 (AM REST needs delegation support)

Copyright and Trademarks Copyright © 2023 ForgeRock, all rights reserved.