The API Gateway Manager features an internal identity provider, allowing users within this system to be assigned to multiple permission groups. These groups enable access to specific functionalities within the API Gateway Manager. This approach, known as Role-Based Access Control (RBAC), is instrumental in granting users tailored access levels to the system, ensuring they have permissions that align with their needs and responsibilities. Importantly, the enforcement of these access controls is consistently applied both in the user interface and within the management API, providing a unified and secure approach to managing user access and permissions.
To create a user in the API Gateway Manager, first, access the Users Menu from the left sidebar. In the Users Menu toolbar, you will find three options:
Invite new Internal User
Create New Internal User
Create New API User
Invite New Internal User sends an email to the specified address, providing a link for the user to set their own password at their convenience.
By selecting Create New Internal User you can create a user account and assign a password directly.
The Create New API User function is designed to establish a service account-type user, which uniquely doesn't require an email address for setup. This category of user is typically utilized for programmatic machine access through the Gateway Manager's REST API. Notably, these API users are not equipped with the capability to log in via the Web User Interface (UI), aligning with their intended use for backend, automated processes rather than direct user interaction.
This type of user can be assigned specific roles, and it's important to clearly define the environments to which it has access. This precise specification ensures appropriate security measures and operational efficiency, tailoring the user's capabilities to the necessary environments only.
Please note that you need to have a SMTP server configured in order to use the “Invite User” feature. |
Both user creation wizards prompt you to select an initial permission group for the new user. Subsequently, you have the flexibility to add more permission groups or modify the original one through the user details view. This approach provides initial access control while allowing for adaptable permissions management as user roles evolve or require adjustments.
If LDAP or SAML authentication is set up within the Configuration → Authentication page, users can access the Gateway Manager using their standard LDAP or SAML credentials, eliminating the need to create user accounts in the Gateway Manager beforehand. However, for security purposes, these users are not automatically assigned any roles upon login. An administrator must explicitly grant the necessary permissions to each user after the user’s initial login.
Typically, a user's LDAP username corresponds to the "User name attribute" or 'cn' (common name), not their email address.
Ensure not to create any user accounts in the User Interface (UI) before the individual has logged in using their LDAP credentials. |
There are 8 different permission groups.
Administrator
This permission group is like a superuser group. It has access to every part of the system. The first user that was created during the Installing process of API Gateway Manager has this permission group preset.
Auditor
This permission group has access to all logs of API Gateway Manager. It can audit them to check for security issues, problems with migrations or any other problems.
Manage Nodes
This permission group has access to all node and environment related functions. It can create new single nodes or cluster to the API Gateway Manager as well as edit those. It can also monitor all nodes on a dashboard to check for availability of the nodes and the status of their services.
Manage APIs
This permission group can import and add new APIs as well as edit and configure them. It can add stage variables to APIs, configure alarms and configure the use of Git for APIs. This role also has access to libraries and solution kits.
Manage Users
This permission group is in charge of all users registered in API Gateway Manager. Users with this group can edit other users to give them more or less permissions, they can edit there email address or password and they can deactivate unused user accounts.
Operator
This permission group has access to dashboards that were made available and to errorlogs. This permission group is perfect for creating a technical user that is used on a beamer/projector or monitor so everyone can watch the real time stats
Perform Migrations
This permission group is in charge of performing a migration. Users who can prepare migrations can assign people with this permission group to perform this migration.
API Developer
This permission group is a subgroup of Manage Services. This permission group can only pull a service from git and prepare migrations as well as assign them to user with a Perform Migrations permission group.
The email is used as the user name for internal users. For other user types, it is taken from LDAP or SAML. Even if it is not the email.
The user's name is displayed in the top right-hand corner and can be freely selected.
Internal users can be locked out of the AAGM by setting the active flag to false.
The user type can be freely changed at the bottom with "Change User Type".
When changing the user type to LDAP or SAML, the current password is removed and the user authenticates from now on only against LDAP or SAML.
The password can only be set for internal and api users.
The roles can be freely added to the user here. A user can also have several roles. For some roles, it must be specified which environments the user may access.
For users not assigned to the administrator permission group, it's essential to specify the environments they can access. Each environment has two distinct permissions that can be assigned: Read and Write. A user with Read permission can view every node and cluster within the specified environment, as well as their statuses. On the other hand, a user granted Write permission has the ability to perform actions corresponding to their assigned permission groups within that environment. This dual-level permission structure allows for both visibility (Read) and operational control (Write), based on the user's role and the permissions granted.