Hide navigation sidebar
Hide table of contents sidebar
Back to top
Toggle table of contents sidebar

# Accounts

Note

Access to the Cluster Manager Users page is restricted to `SYSADMIN` users.

## Users

To access the Cluster Manager, a user needs an account and the appropriate credentials to authenticate against that account.

### Overview

#### User Roles

Cluster Manager users will have one of four user roles:

- Standard user

  A standard user submits jobs or batches to the cluster. This is done through a user application, the Gurobi command-line tools, or interactively using the Cluster Manager Web Interface.

- Administrator

  An administrator monitors and manages the flow of jobs and batches submitted by standard users. The administrator can abort or discard jobs or batches, change some cluster parameters, and check node licenses.

- System administrator

  The system administrator is in charge of managing user accounts and cluster nodes.

- Read-only user Read-only users can only monitor optimization tasks. They can list jobs and batches, access job history, display the log of a job, etc. They are not allowed to submit jobs or batches to the cluster, nor can they abort jobs.

#### Authentication Type

The Cluster Manager supports two types of authentication:

- Interactive login

  An interactive login requires the user to provide their username and password. Upon successful login, the server generates a session token which is valid for a relatively short period of time (default is 8 hours and can be changed in the Cluster Manager settings). The user will not be asked to log in again until this token has expired, which is handy when using the Web User Interface or the command-line tools. Interactive login can also be mapped to an LDAP server for centralized management. If SAML is configured this interactive login will be managed by the Identity provider configured.

- API keys

  When using an API key, the user or application must provide an access ID and a secret key. When creating an API key, you can specify an optional application name and description to help keep track of how the key is being used. Once a key is created, you can download an associated client license file, which contains the API access ID, the secret key, and the Cluster Manager URL. This license file can be used by client applications and command-line tools to connect to the Cluster Manager. The Cluster Manager keeps track of the timestamp and IP address of the last API key usage.

The system administrator can enable or disable interactive login or API Key authentication, either at creation time, or it can be done later by editing the account properties. An account that only allows interactive login will not be allowed to create, use and manage API keys. An account that only allows API key authentication (known as a system account) can only be used for programmatic access through the REST API.

#### LDAP Integration

The Cluster Manager can be integrated with an LDAP repository. This integration can be configured in the Cluster Manager settings section. The system administrator can specify connection parameters (including the use of LDAPS for encrypted communication), account filtering, and account mapping. Once activated, users will be given access based on the user accounts defined in the LDAP server. Only accounts with a system administrator role will be able to log in using their local passwords.

System administrators need to log in using a special login page by following the link “System Administrator Log in” at the top of the main login page. They have local accounts that enable them to administer the cluster even if there is a problem with the LDAP configuration. System accounts (i.e., accounts with no interactive login) can always gain access using API keys.

The Cluster Manager continually synchronizes user accounts with the LDAP server in the background. If a given user account is no longer mapped to the LDAP filter in place, it will be disabled. In particular, if an account was created before the integration with the LDAP sever and if it is not mapped to the defined LDAP filter in place, it will be disabled. The same policy will apply during migration from local accounts to LDAP. Two important exceptions are system administrator accounts and system accounts, which will not be disabled for this reason.

Note that it may be necessary to rename and merge users when migrating an existing Cluster Manager setup from local authentication to LDAP authentication, to avoid losing API keys and job history when the username is adjusted to match the LDAP username.

#### SAML Integration

The Cluster Manager can be integrated with a SAML 2.0 directory. This integration can be configured in the Cluster Manager settings section. The system administrator can specify connection parameters and account mapping. Once activated, users will be given access based on the user accounts defined in the SAML directory. Accounts with a system administrator role can log in using their local passwords, which enables them to administer the cluster even if there is a problem with the SAML configuration. System administrators will need to log in using the special login page by accessing the `/login/admin` link at the top of the main login page. System accounts (i.e., accounts with no interactive login) can always gain access using API keys.

Once SAML 2.0 has been configured, the `SYSADMIN` can login using the page mentioned above with the local system password set in the Cluster Manager, or using the regular SAML Login flow if the `username` matches the user provided by the IdP.

If a user is enabled in SAML but disabled in cluster manager, a redirection to the error page will be performed and, a log in the system will indicate the cause.

After configuring SAML 2.0 as the Authentication Provider, the username attribute mapping will be employed to associate existing users. Any user not found in the system will be treated as a new user. If it is necessary for existing users to match the format of new usernames, system administrators can rename the users to the desired format in the user table.

#### Command line login for SAML with `grbcluster`

If the cluster manager is configured for SAML Authentication, it’s essential to follow the authorization flow for secure access.

When you initiate the login process, the cluster manager will generate a unique URL along with a Device ID Code. By default, this action will automatically open a web browser for your convenience. However, if you wish to disable this automatic browser launch, you can use the `--no-browser` flag.

The login operation itself must be conducted within the web browser. It’s important to clarify that this web browser doesn’t have to be on the same machine where the login was initiated. You can access it from any device that has connectivity to the cluster manager. This flexibility ensures that you can perform the authorization operation from a location that is most convenient for you.

### The Users Page

The Users page lists the users of this Cluster Manager.

1. This page shows a table of all batches that have been created on the Cluster Manager (created, aborted, and completed). Each line in the table provides information about a batch, including the current status, the creation and completion times, the priority, and the API used to create the job. The current batch status is shown using an icon:

   > | User is enabled for interactive login and API keys.
   > | User is currently disabled, but could use interactive login and API keys if enabled.
   > | User is enabled for interactive login only.
   > | User is disabled, but could use interactive login if enabled.
   > | User is enabled for API key use only (system account).
   > | User is disabled, but could use API keys if enabled.

2. 3. Users displayed in the table can be filtered using either the Filter box or the Search box. Details can be found in the Filtering and Searching section.

4. 5. The number of rows of the table.

   When the table has been filtered, two numbers are displayed to the right of the page title showing respectively the number of users matching the current filtering and the total number of users. If no users have been filtered, only the total number of users wil be displayed.

6. The CREATE USER button opens a dialog to create a user.

7. The EDIT button opens a dialog that allows you to edit information about the user.

8. The MENU button opens a menu that gives access to various actions that can be performed on a user account (e.g., deleting or disabling the user).

#### Filtering and Searching

Users displayed in the table can be filtered using the Filter box and the Search box.

##### Filtering

The Filter box provides the user with a set of predefined filters as shown below:

| When clicking on the left icon of the filter box, a dialog is displayed to edit the filters to apply.

##### Searching

The Search box enables users to further refine the results by specifying an arbitrary search string. In order for a user to be displayed, the search string must be present in at least one of the columns in the table for that user.

Note

It is important to note that filtering with the Filter box is usually applied server side, while searching with the Search box is always performed client side. That means that the searching is done on results that were already filtered by the server, so it it is preferable to use the Filter box first and then use the Search box to refine the results. Using the Search box as an alternative to the Filter box could result in missing items.

##### Synchronization with page URL

The Cluster Manager creates permalinks for all tables that can be filtered or searched. Changes applied using either the Filter or Search boxes are automatically reflected in the page URL, thus allowing you to copy and paste the URL to easily retrieve the same display later. For example, the URL `http://localhost:61080/accounts/users?role=ADMIN` would display only users with ADMIN roles (assuming the Cluster Manager is running on `localhost:61080`).

#### Creating a User

The CREATE USER button (6) opens a dialog that allows you to provide the necessary properties for a new user and create an account.

Any property except the Username can be edited after the account has been created. Usernames must be unique among all users registered to a Cluster Manager.

#### Editing a User

User properties can be edited using the EDIT button (7).

#### Deleting a User

System administrators can delete a user:

- Click on the menu button (8) for the user and select the Delete User menu item.

- Confirm the deletion.

Warning

Deleting a user is permanent and cannot be undone.

#### Disabling a User

Disabling a user temporarily revokes all access from that user (interactive login and API keys). To disable a user:

- Click on the menu button (8) for the user and select the Disable User menu item.

- Confirm the user can be disabled.

- Once the user has been disabled, the authentication type icon will be grayed out:

#### Enabling a User

A system administrator can follow similar steps to enable a user:

- Click on the menu button (8) for the user and select the Enable User menu item.

- Once the user has been enabled, the authentication type icon will no longer be grayed out:

#### Changing User Password

When creating a new user, the system administrator must define a password to enable the user to interactively log in to the Cluster Manager. Users can later change their passwords from their profile page. A system administrator can also change a user password (e.g., if the user forgot their password):

- Click on the menu button (8) for the user and select the Change Password menu item.

- Enter a new password for the user.

  If the password does not comply with password policy, the Apply button will be disabled, and hints will be displayed in red for fixing the problem.

Note

Passwords must comply with the chosen Password Policy for the Cluster Manager, as defined in the Password Policy settings.

#### Renaming a User

The system administrator can give a user a new username. That changes the username of that user permanently. When renaming a user, all the API keys, job history and batch history will be owned by the new username. If a user is renamed and there is already a user with that name, the Cluster Manager will give the option to merge the two accounts. That merged user would then own all of the API keys, job history and batch history of the original user.

To rename a user:

- Click on the menu button (8) for the user and select the Rename User menu item.

- In the dialog that pops up, enter a username for the new user.

- If the specified username matches the username of an existing user, a dialogs pops up to confirm that the two accounts should be merged:

## API Keys

An API key (Application Programming Interface key) is composed of an access ID and a secret key, API keys are the recommended approach for connect applications to the Cluster Manager. When the Cluster Manager authenticates access using an API key, all actions are performed on behalf of the user who owns that key. There are two ways to create an API key:

- The user can create their own API key from the API keys page.

- The system administrator can create an API key on the behalf of a user from the system administrator Accounts API keys page.

When creating an API key, you can specify an optional application name and description to help keep track of how the key is being used. Once a key is created, you can download an associated client license file, which contains the API access ID, the secret key, and the Cluster Manager URL. This license file can be used by client applications and command-line tools to connect to the Cluster Manager. The Cluster Manager keeps track of the timestamp and IP address of the last API key usage.

An API key can be enabled or disabled by either the owner or the system administrator.

This set of API key features was designed to simplify the task of monitoring API keys, detecting unwanted usage, and safely rotating keys by disabling previous keys before permanently deleting them.

### The API Keys Page

The API Keys page allows the system administrator to manage keys owned by users of the Cluster Manager.

1. This page provides a table of API keys. Keys can be sorted by various attributes by clicking on the corresponding column headers. Up and down arrow icons allow you to select the sorting direction.

   The icon in the first column shows the status of each API key:

   | API key is enabled and can be used to access the Cluster Manager API.
   | API key is disabled and cannot be used to access the Cluster Manager API.

2. 3. API keys displayed in the table can be filtered either using the Filter box or the Search box. Details can be found in the Filtering and Searching section.

4. 5. The number of rows of the table.

      When the table has been filtered, two numbers are displayed to the right of the page title showing respectively the number of API keys matching the current filtering and the total number of API keys. If no users have been filtered, only the total number of API keys wil be displayed.

7. The CREATE API KEY button opens a dialog to create an API key.

8. The EDIT button opens a dialog to edit the API key.

9. The MENU button opens a menu that gives access to various actions that can be performed on the API key (e.g., deleting or disabling the key).

#### Filtering and Searching

API keys displayed in the table can be filtered using the Filter box and the Search box.

##### Filtering

The Filter box provides the user with a set of predefined filters as shown below:

| When clicking on the left icon of the filter box, a dialog is displayed to edit the filters to apply.

##### Searching

The Search box enables users to further refine the results by specifying an arbitrary search string. In order for an API key to be displayed, the search string must be present in at least one of the columns in the table for that key.

Note

It is important to note that filtering with the Filter box is usually applied server side, while searching with the Search box is always performed client side. That means that the searching is done on results that were already filtered by the server, so it it is preferable to use the Filter box first and then use the Search box to refine the results. Using the Search box as an alternative to the Filter box could result in missing items.

##### Synchronization with page URL

The Cluster Manager creates permalinks for all tables that can be filtered or searched. Changes applied using either the Filter or Search boxes are automatically reflected in the page URL, thus allowing you to copy and paste the URL to easily retrieve the same display later. For example, the URL `http://localhost:61080/accounts/keys?appname=MyApp` would display only API keys associated with the MyApp application (assuming the Cluster Manager is running on `localhost:61080`).

#### Creating an API Key

The CREATE API KEY button (7) opens a dialog that allows you to provide the necessary properties and create a new API key.

#### Editing an API Key

The EDIT button (8) opens a dialog that allows you edit the properties of an API key:

#### Deleting an API Key

System administrators can delete an API key:

- Click on the menu button (9) for the API key and select the Delete API Key menu item.

- Confirm the API key can be deleted.

#### Disabling an API Key

System administrators can also disable an API key:

- Click on the menu button (9) for the API key and select the Disable API Key menu item.

- Confirm the API key can be disabled.

- Once the API key has been disabled, the icon in the first column will be grayed out:

#### Enabling an API Key

The system administrator can follow similar steps to enable an API key:

- Click on the menu button (9) for the API key and select the Enable API Key menu item.

- Once the API key has been enabled, the icon in the first column will no longer be grayed out:

Help and Feedback

Press `/` or click to search this documentation | Gurobi website | Gurobi community forum
Go to other Gurobi documentation | Gurobi download | Contact support