Security Settings

We have carefully selected the security configuration of the RapidMiner Platform deployment to ensure high security standards are met. In most cases, some adjustment to these defaults will be needed to ensure compliance with the (enterprise) deployment environment, or finding a good balance between ease of use and security.

Below you can find guides to carry out common tasks related to the security of the deployment.

Pre-requisites

To carry out the management tasks described below, you need to be logged in with a user that has the appropriate role assigned. In our default configuration, this role is covered by the platform-admin realm role, which is assigned to the pre-provisioned admin user.

After logging in, navigate to Identity and Security on your deployment's landing page to access the admin interface. All instructions below assume that you are already logged in and navigated to this page.

Managing password security

This feature will allow you to set password complexity requirements, password hashing configuration, and password expiration policies.

By default, we have configured a basic set of password policies to ensure a good baseline level of password security. Passwords will require to be 6 characters long, cannot be the same as the username, and cannot be on a configured blacklist of common passwords.

To add a new policy, go to Authentication, and click on the Password Policy tab.

From the Add Policy dropdown, select the policy you wish to configure, then set the desired value. As an example, to set a one month password expiration policy, add Expire Password with a value of 30.

You can add multiple policies, each of them will be enforced when setting passwords.

Note: password policies only apply to users managed by RapidMiner Identity and Security. In case of federated identity or a federated user database, you need to set the password policies in these respective systems.

Configuring two-factor authentication

Two-factor authentication (using Google Authenticator or FreeOTP) are supported. By default, it's an optionally configurable security measure available for all users. As a user, you can configure it on your Account page.

Two-factor authentication can also be configured to be mandatory, in which case it will be a requirement of a successful first login.

To make two-factor authentication mandatory, go to Authentication, and click on the Required Actions tab.

Check Default Action in the row of Configure OTP.

The setting takes effect immediately, all new users will be required to configure two-factor authentication.

Configuring transport security (HTTPS)

Starting with Altair AI Hub version 2025.0, AI Hub no longer supports plain HTTP. Hence, you must obtain a secure certificate from a trusted Certificate Authority, either a public issuer or a corporate CA that is trusted by all devices that have access to the deployment.

Alternatively, you can use Let’s Encrypt, a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG).

The letsencrypt Docker image provided with AI Hub contains the Certbot application which is the official client application for https://letsencrypt.org/.

When performing initial deployment based on a template, the services will start up and work using unencrypted HTTP communication. This path was chosen to simplify the initial hurdles of deployment, but for long-running development/testing and production deployments we strongly recommend configuring encryption over the wire.

As a prerequisite, the administrator needs to procure a secure certificate from a trusted Certificate Authority, which is out of scope for this document. The certificate must be issued for the public URL where the deployment will be accessible, and the certificate file (containing the full certificate chain) and the private key file need to be at hand.

Using a self-signed or company-internal certificate (i.e. one not signed by a trusted Certificate Authority) is not supported out of the box. If the used certificate is not trusted by a Certificate Authority, the individual components of the platform will not be able to use this, unless each components adds the certificate to their trusted certificate stores.

If you need to secure the RapidMiner Platform using a self-signed or company internal certificate, contact our support team to help get it done.

To install a certificate to be used in the RapidMiner Platform:

On the host machine where the deployment is running, copy the .crt and .key files to the ssl folder that exists beside your docker-compose.yml. Create the folder if it doesn't exist yet. The files should be named certificate.crt and private.key, respectively. Make sure the certificate file contains the full certificate chain.
Generate your dhparam file by running openssl dhparam -out ssl/dhparam.pem 2048. Depending on your machine, this might take several minutes.
Using your favorite text editor, edit the .env file and replace http:// with https:// in your PUBLIC_URL and PUBLIC_SSO_URL variables
Run docker-compose up -d to update your deployment.

After this procedure is done, you will no longer be able to access the deployment on plain HTTP. Trying to connect on port 80 will get you redirected automatically to port 443, where HTTPS based communication will be done.

Configuring email

The RapidMiner Platform's integrated KeyCloak component can be configured to use an SMTP server to send emails. This is needed in certain user management related use cases. Here are some examples:

allowing self-signup, which requires verification emails to be sent
sending password reset emails

To configure email, go to Realm Settings, and click on the Email tab.

Add the details of your SMTP server which will be used by KeyCloak to send emails.

If you want to enable some of the above examples to ease self service user management, go to the Login tab and enable the desired features.

Checking audit logs

We can log and display two sets of events: login events and admin events. In the RapidMiner Platform deployment, both are configured to be saved to the database and queried/filtered on the Identity and Security interface.

Login events are various types of events related to user login, authentication and authorization and their related errors.

Admin events are changes made in the KeyCloak configuration.

To query and filter these events, go to Sessions and click on the Login Events or Admin Events tab, depending on the set of information you would like to review.

To configure what events are saved, and for how long (only in case of Login events), go to the Config tab.

You can customize what types of login events are saved (some of them might be superfluous and fill up your database too quickly). To do this, add or remove items from the Saved Types box.

You can customize how long the events are kept for. To do this, set the desired values in the Expiration field.

For a more detailed description, check out the relevant section of the KeyCloak administration guide.

Checking active sessions and revoking tokens

It is prudent to check in on what components are used in the deployment and by whom.

In the case when a breach is suspected (e.g. a user's credentials are suspected stolen), it might be prudent to invalidate current logins and tokens.

To check ongoing sessions, go to Sessions. The Realm Sessions tab will show all realm clients (i.e. deployment components) which have active sessions. Clicking on one of the clients will give you a detailed list of which users have active sessions and their source IP address.

You have the option to end all sessions by going to Sessions and clicking the Logout all button.

To invalidate possibly stolen tokens, go to Sessions and click on the Revocation tab. By clicking the Set to now button, you can invalidate all tokens issued before the current time.

Categories

Versions