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 Security Guide › About 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:
You can delegate tasks based on privileges. See How do I add privileges to identity groups in AM (All versions)? and Security Guide › Delegating 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 Security Guide › Delegating 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 Security Guide › Delegating 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.
- Changing the amAdmin user's password. See Security Guide › About 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-based sessions are configured (but a delegated administrator can).
- Using the following directory JSP endpoints, which are detailed in Reference › JSP Files:
- Logback.jsp (AM 7 and later)
- Debug.jsp (pre-AM 7)
- ssoadm.jsp (this page was removed in AM 5.5, deprecated in AM 5 and deactivated by default prior to that to prevent potential misuse)
- Triggering the following workflow tasks accessed from the realm level Common Tasks page (pre-AM 7) - these workflows are triggered by the AjaxProxy.jsp endpoint, which is detailed in Reference › 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 console (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.
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.