User Management Extension in the IAM Adminapp
With user management extensions (UMEs), the user and token management UI in the IAM Adminapp can be extended JavaScript (JS) code. It allows adding a custom tab to the user detail page that can be filled with custom content and, e.g., interact with a custom REST API.
This article explains how to configure and develop UMEs in the IAM Adminapp.
Introduction
The following screenshot shows a very simple “Hello World” user management extension (UME) on the user detail page of user jdoe.
User management extensions (UMEs) are displayed as separate tabs on the user detail screen and can be used to implement custom management features on users and users' tokens.
UMEs are designed to do the following:
- Provide a custom UI for user-centric data.
- Call existing IAM REST APIs.
- Call REST APIs from a Generic Token Controller (e.g., for custom authentication tokens)
- Call custom REST endpoints from custom REST extensions or external systems.
Generic Token Controllers are an alternative but less flexible way of implementing custom user management features.
Creating and configuring a UME
Creating and configuring a UME involves the following steps:
- Create the actual UME JavaScript code (see below and linked examples) and register it using a unique UME ID.
- Save the UME JavaScript code in a file named
user-management-extensions.js
and store it in the IAM instance's Adminapp layout folder.
The Adminapp layout folder is defined in theinstance.properties
file by propertyiam.adminapp.layout.dirs
and defaults toinstances/<instance-name>/adminapp-layout/
. - Add the required translations for text elements to
instances/<instance-name>/adminapp-texts/string_xx.properties
. - List the UME ID in the IAM configuration: Adminapp >> Users >> User Management Extensions.
- Adapt access control settings in Adminapp >> Access Control >> Display User Management Extensions so entitled admin users can see the UME.
Writing the UME JavaScript
UMEs are written in JavaScript and reside in the file adminapp-layout/user-management-extensions.js
(relative to the folder of the affected IAM instance). The file may contain several UMEs.
A UME consists of two parts:
- The UME's class definition.
- A method-call registering the UME class in the Adminapp.
The following methods from the IAM API are available in UMEs:
iam.api.userManagementExtension.register(ID, UME Class)
: used to register a UME in the Adminapp (see example above).iam.api.userManagementExtension.userId()
: returns the ID of the selected user.iam.api.userManagementExtension.adminId()
: return the ID of the logged-in administrator.iam.api.userManagementExtension.adminRoles()
: returns the array of roles of the logged-in administrator.iam.api.userManagementExtension.reloadUser()
: can be called to reload the user (e.g. after modifying user data via a REST call).iam.api.translate(key, attributes)
: used to translate text elements.
API usage and limitations
Consider the following when developing UMEs:
- Only the mentioned JS API functions from IAM may be used. Calls to other IAM-specific JS functions may change at any time.
- None of IAM's CSS classes may be used. They are considered implementation details of Airlock IAM that may change at any time. If the UME defines CSS classes, they must be prefixed with
ume-<ume-id>-
. To prevent IAM styles from leaking into the application, we recommend encapsulating the user management extension in a Web Component. - The UME must not manipulate or interact with any DOM Elements, except the UME's root and its children.
- Keep in mind, that REST requests are executed in the scope of the Adminapp's session. This also implies that calls to protected API endpoints can be made with the session cookie of the logged-in Adminapp user.
User management extensions bear risks. They allow using the full power of JavaScript combined with the possibility of executing any Adminapp REST call with the privileges of the logged-in admin user.
Consider the following when implementing UMEs:
- REST requests can be made with the session cookie of the logged-in Adminapp user.
- Consider security implications carefully if changes to the CSP are necessary to call, for example, 3rd party scripts.
- Do not implement access control just in the UME: the UME code is running in the browser and can therefore be manipulated. Access control has to be implemented on the server side. For example, do not use the method
shouldShow()
to implement access control. - The access control settings in Adminapp >> Access Control >> Display User Management Extensions (fine-grained) only determines whether a UME is displayed to the admin or not. It does not implement server-side REST API access control. Without additional proper server-side access control, an admin user may not see the UME but may possibly still call the REST endpoints.