You are viewing the RapidMiner Go documentation for version 10.1 - Check here for latest version
RapidMiner Identity (RMID)
RMID is the authentication and authorization service used by RapidMiner Go.
Configuration
There are 2 levels of configuration for RMID:
- Spring profiles
- environment variables
RMID is a Spring Boot application and so it can be configured using the SPRING_PROFILES_ACTIVE environment variable in docker-compose.yml.
This a comma separated list of the active spring profiles.
Available profiles:
| Spring profile | Description |
|---|---|
| db-postgresql | RMID uses PostgreSQL database |
| is-db | use DB as identity provider |
| is-auth0 | use Auth0 IDP |
| is-ldap | use LDAP IDP |
| is-saml | use SAML IDP |
| on-prem | On-prem installation |
The default value is db-postgresql,is-db,on-prem - this means that default database is PostgreSQL, and default identity provider is the internal database, and the application is running on-prem.
Using environment variables
On top of these profiles you can also specify environment variables -- these will override the default value of the profiles.
Table of default environment variables:
| Environment variable name | Description |
|---|---|
| DB_HOST | docker service for DB, default is rapidminer-automodel-db |
| BASE_URL | external base URL used on the frontend - e.g. https://localhost:30000 |
| AUTH_SECRET | authentication secret used between services -- i.e AM and RMID |
| RMID_FRONTEND_TRACKING_ENABLED | enable event tracking service (internal analytics) |
| TOKEN_MAX_AGE | how long the authentication token is valid in seconds - default 1 day |
| _JAVA_OPTIONS | Java options directly passed to the JVM. Use this to configure memory settings and others |
Database
RMID has its own database -- in the default docker setup this is in the same container/database instance as RapidMiner Go's database -rapidminer-automodel-db -- but it could be in a separate database instance.
The only supported database profile is db-postgresql.
Identity providers
RMID can be configured to use several identity providers (IDP) to authenticate users.
The following table shows the different IDP's and the corresponding spring profile:
| IDP | Spring profile | Protocol | Login UI/method | Configuration |
|---|---|---|---|---|
| DB | is-db | N/A | username/password form, HTTP POST | DB_HOST DB_PORT DB_NAME DB_USER DB_PASSWORD |
| Auth0 | is-auth0 | OAuth2 password grant | username/password form, HTTP POST | AUTH0_URL AUTH0_KEY_URL AUTH0_CLIENT_ID AUTH0_CLIENT_SECRET |
| LDAP capable 3rd party IDP(*) | is-ldap | LDAP | username/password form, HTTP POST | LDAP_URL LDAP_MANGAGER_DN LDAP_MANGAGER_PASSWORD LDAP_USER_SEARCH_BASE LDAP_USER_SEARCH_FILTER |
| SAML capable 3rd party IDP | is-saml | SAML | hyperlink redirecting to SAML provider | SAML_ENTITY_ID SAML_KEYSTORE_PASSWORD SAML_KEYSTORE_ALIAS |
Multiple IDPs can be switched on -- in that case RMID will try to authenticate with all of them until it succeeds.
(*) the LDAP manager password has to be provided base64 encoded
Usage
RMID Login screen can be accessed at /rmid/auth.
The login type is determined by the configured IDP -- it is a username/password form for DB, LDAP, AUTH0, and for SAML it is a link redirecting to the SAML IDP.
If SAML and another IDP are used together, you have to explicitly configure a dual login type with the help of the environment variable: RMID_FRONTEND_LOGINTYPE: LOGINTYPE_DUAL -- this will display a login form and redirect link together.
After a successful login, the user is automatically redirected to RapidMiner Go. After a successful logout from RapidMiner Go, the user is redirected back to RMID.
Administration
RMID Administration app can be accessed at /rmid/admin -- default credentials are admin/changeit.
Users
For each user there is an entry in the RMID_USERS table and one entry in the profile tables for the configured IDPs.
RMID_USERS table contains user's displayName and a few RapidMiner Go related fields.
Users can be banned by switching off active field. This results in the user being logged out from RapidMiner Go (and any service using RMID) within 5 minutes (configurable in the service).
User profiles
The profile tables contain user data coming from a specific IDP.
Local users are created and updated in the admin app -- they are stored RMID_PROFILE_LOCAL table.
External profiles are read-only in the admin -- their content is created and updated during login based on user info from the external IDP.
For instance, if is-auth0, is-saml profiles are active, RMID_PROFILE_LOCAL, RMID_PROFILE_SAML tables will contain user data coming from these IDPs.
In this case, the User view in the Admin app will contain 3 forms:
- one editable form for the users table (displayName, active, acceptEula)
- 2 read-only forms for the 2 profiles -- saml and auth0
The following table lists IDPs and profile tables:
| IDP | Profile table | Admin operations | Display name |
|---|---|---|---|
| DB | RMID_PROFILE_LOCAL | CRUD | username |
| Auth0 | RMID_PROFILE_AUTH0 | R | Auth0 nickname |
| SAML | RMID_PROFILE_SAML | R | SAML name assertion |
| LDAP | RMID_PROFILE_LDAP | R | LDAP username |
Example:
If Auth0 is configured as IDP, a user sign-in with Auth0 credentials will create an entry in RMID_USERS table and an entry in RMID_PROFILE_AUTH0 table if necessary.
Auth0 nickname will be stored in profile table and also copied to RMID_USERS displayName field.
On later logins nickname and displayName will be updated for this user if there was a change on the IDP side.
The default display name mapping can changed in the case of SAML.
Groups, roles, privileges
RMID defines a role based authorization system on the service level governed by these entities:
User ↔ Group ↔ Role ↔ Privilege
The entities are in many-to-many relationship.
A user can access specific API endpoints and URLs based on the privileges he or she has. Privileges are predefined in the system and read-only. However privileges are not directly assigned to users, but to roles. Roles are predfined sets of privileges. Roles are assigned to groups and finally users are assigned to groups.
For example to give admin right to a user you would add the user to the RMID_ADMIN group. This group has by default ADMIN role assigned, and ADMIN role has the 'rmid:admin' privilege assigned.
This system enables fine grained control but is also powerful.
Groups can be created freely to reflect organisational hierarchy or for the needs of a data-science project.