Configuring Management Center

If you have started the Management Center from the command line by using the JAR file, by default, the sessions that are inactive for 30 minutes are invalidated. To change this, you can use the -Dhazelcast.mc.session.timeout.seconds command line parameter.

For example, the following command starts the Management Center with a session timeout period of 1 minute:

If you have deployed the Management Center on an application server/container, you can configure the default session timeout period of the application server/container to change the session timeout period for the Management Center. If your server/container allows application specific configuration, you can use it to configure the session timeout period for the Management Center.

Normally, a user account on the Management Center can be used from multiple locations at the same time. If you want to forbid others from logging in, when there’s already someone logged in with the same username, you can start the Management Center with the -Dhazelcast.mc.allowMultipleLogin=false command line parameter.

In order to prevent password guessing attacks, logging in is disabled temporarily after a number of failed login attempts. When not configured explicitly, the default values are used, i.e., logging in is disabled for 5 seconds when a username is failed to log in consecutively 3 times. During this 5 seconds of period, logging in is not allowed even when the correct credentials are used. After 5 seconds, the user will be able to log in using the correct credentials.

Assuming the configuration with the default values, if the failed attempts continue (consecutively 3 times) after the period of disabled login passes, this time the disable period is multiplied by 10: logging in is disabled for 50 seconds. The whole process repeats itself until the user logs in successfully. By default, there’s no upper limit to the disable period, but can be configured by using the -Dhazelcast.mc.maxDisableLoginPeriod parameter.

Here is a scenario, in the given order, with the default values:

You can configure the number of failed login attempts, initial and maximum duration of the disabled login and the multiplier using the following command line parameters:

If you haven’t allowed multiple simultaneous login attempts explicitly, the first user to login with a username stays logged in until that username explicitly logs out or its session expires. In the meantime, no one else can login with the same username. If you want to force logout for the first user and let the newcomer login, you need to start Management Center with the -Dhazelcast.mc.forceLogoutOnMultipleLogin=true command line parameter.

To encrypt data transmitted over all channels of the Management Center using TLS/SSL, make sure you do all of the following:

When you start the Management Center from the command line, it serves the pages unencrypted by using "http", by default. To enable TLS/SSL, use the following command line parameters when starting the Management Center:

You can leave the truststore and truststore password values empty to use the system JVM’s own truststore.

The following is an example on how to start the Management Center with TLS/SSL enabled from the command line:

You can access the Management Center from the following HTTPS URL on port 8443: https://localhost:8443.

On the member side, you need to configure the Management Center URL as https://localhost:8443 and also set the following JVM arguments when starting the member:

To override the HTTPS port, you can use the -Dhazelcast.mc.https.port command line option when starting the Management Center. For example:

This starts the Management Center on HTTPS port 443.

You can configure Management Center to require mutual authentication. With this setup, any client (be it a Web browser or an HTTP client such as curl) needs to present their TLS certificate and the Management Center needs to have its truststore configured so that the Management Center can know which clients it can trust. To enable mutual authentication, you need to use the following command line parameters when starting the Management Center:

See the below snippet to see the full command to start the Management Center:

The parameter -Dhazelcast.mc.tls.mutualAuthentication has two options:

In order to prevent certain words from being included in the user passwords, you can start the Management Center with -Dhazelcast.mc.security.dictionary.path command line parameter which points to a text file that contains a word on each line. As a result, the user passwords will not contain any dictionary words, making them harder to guess.

The words in the dictionary need to be at least three characters long in order to be used for checking the passwords. The shorter words are ignored to prevent them from blocking the usage of many password combinations. You can configure the minimum length of words by starting the Management Center with -Dhazelcast.mc.security.dictionary.minWordLength command line parameter and setting it to a number.

An example to start the Management Center using the aforementioned parameters is shown below:

When you configure TLS you also can provide which cipher suites Management Center can use for establishing TLS connection. You can include cipher suites with -Dhazelcast.mc.include.cipher.suites and exclude with -Dhazelcast.mc.exclude.cipher.suites system properties during Management Center startup. You can use the exact cipher suite name or a regular expression. For example:

When you run mc-conf.sh or mc-conf.bat, the script checks if there is any running Management Center instance by looking for a lock file called mc.lock in the Management Center home directory, and exits with an error if the file exists. You can turn this behavior off by passing the -Dhazelcast.mc.lock.skip=true system property. Example:

You may enable additional security audit logging by using the -Dhazelcast.mc.auditlog.enabled=true command line argument. Log entries from the audit logging will be marked with the hazelcast.auditlog logging category, abbreviated as h.auditlog in logs.

An example log entry looks like the following:

MC-2001 [Auth] you see in this example represents the log’s type. The following table lists the current log categories along with their types:

To write security audit logging into separate rolling log files, you can use a similar Log4j configuration file:

This example EncryptionReplacer replaces the encrypted variables with its plain form. The secret key for encryption/decryption is generated from a password which can be a value in a file and/or environment specific values, such as MAC address and actual user data.

Its full class name is com.hazelcast.webmonitor.configreplacer.EncryptionReplacer and the replacer prefix is ENC. Here are the properties used to configure this example replacer:

As a usage example, let’s create a password file and generate the encrypted strings out of this file as shown below:

PropertyReplacer replaces variables by properties with the given name. Usually the system properties are used, e.g., ${user.name}.

Its full class name is com.hazelcast.webmonitor.configreplacer.PropertyReplacer and the replacer prefix is empty string ("").

You can also provide your own replacer implementations. All replacers have to implement the three methods that have the same signatures as the methods of the following interface: