In this section we describe how to configure and use specific features of this midPoint dockerization.

Repository

Logging is configured by setting Repository configuration is done via the following environment variables:.

Environment variable	Meaning	Default value
`ENV`	environment (e.g. prod, dev, test)	`demo`
`USERTOKEN`	arbitrary user-supplied token

According to the specification, semicolons and spaces in these fields are eliminated. We decided to replace them by underscores.

Repository

Repository configuration is done via the following environment variables.

Environment variable	Meaning	Default value
`REPO_DATABASE_TYPE`	Type of the database. Supported values are `mariadb`, `mysql`, `postgresql`, `sqlserver`, `oracle`. It is possible to use `H2` as well but H2 is inappropriate for production use.	`mariadb`
`REPO_JDBC_URL`	URL of the database.	MariaDB: `jdbc:mariadb`
`REPO_DATABASE_TYPE`	Type of the database. Supported values are `mariadb`, `mysql`, `postgresql`, `sqlserver`, `oracle`. It is possible to use `H2` as well but H2 is inappropriate for production use.	`mariadb`
`REPO_JDBC_URL`	URL of the database.	MariaDB: `jdbc:mariadb://$REPO_HOST:$REPO_PORT/$REPO_DATABASE?characterEncoding=utf8` MySQL: `jdbc:mysql://$REPO_HOST:$REPO_PORT/$REPO_DATABASE?characterEncoding=utf8` PostgreSQL: `jdbc:postgresql://$REPO_HOST:$REPO_PORT/$REPO_DATABASE` SQL Server: `jdbc:sqlserver://$REPO_HOST:$REPO_PORT;database=$REPO_DATABASE` Oracle: `jdbc:oracle:thin:@$REPO_HOST:$REPO_PORT/xe`
`REPO_HOST`	Host of the database. Used to construct the URL.	`midpoint_data`
`REPO_PORT`	Port of the database. Used to construct the URL.	3306, 5432, 1433, 1521 for MariaDB/MySQL, PostgreSQL, SQL Server and Oracle, respectively
`REPO_DATABASE`	Specific database to connect to. Used to construct the URL.	`registry`
`REPO_USER`	User under which the connection to the database is made.	`registry_user`
`REPO_PASSWORD_FILE`	File (e.g. holding a docker secret) that contains the password for the db connection.	`/run/secrets/mp_database_password.txt`
`REPO_MISSING_SCHEMA_ACTION`	What should midPoint do if the database schema is missing (options: `warn`, `stop`, `create`).	`create`
`REPO_UPGRADEABLE_SCHEMA_ACTION`	What should midPoint do if the database schema is obsolete but upgradeable (options: `warn`, `stop`, `upgrade`). As of midPoint 3.9, the only automated transition available is from 3.8 to 3.9.	`stop`
`REPO_SCHEMA_VERSION_IF_MISSING`	For midPoint versions before 3.9 that do not have schema information explicitly stored in the database, this parameter allows specifying the version externally. It can be used for automated upgrade from 3.8 to 3.9. (In such cases, specify it to be 3.8, assuming this is your schema version.)
`REPO_SCHEMA_VARIANT`	Used to specify what schema variant is to be used for automated creation or upgrade of the database schema. Currently the only known variant is `utf8mb4` for MySQL/MariaDB. Beware: it is the administrator's responsibility to choose the correct variant! Currently midPoint does not try to determine the variant present in the database. So be sure to avoid applying e.g. `mysql-upgrade-3.8-3.9-utf8mb4.sql` if the database is not in `utf8mb4` character set, or vice versa.

For automatic schema creation and upgrade options please see Schema creation and updating section in midPoint documentation.

Besides that, the following Docker secrets are usedNote that in order to connect to the database you have to provide the password. For security reasons, we use the indirect way through file access. So, typically you provide the following Docker secret:

Secret	Meaning

Location

Typical location in demonstration scenarios
`mp_database_password.txt`

The default location of the

A password used to

connect to the database

access the repository (relates to REPO_USER). configs-and-secrets/midpoint/application/database_password.txt

Authentication

This midPoint dockerization supports two authentication mechanisms.

Of course, you can provide the password file in any other way, assuming you correctly set REPO_PASSWORD_FILE environment variable.

Logging

Logging is configured by setting the following environment variables:

Environment variable	Meaning	Default value
`ENV`	environment (e.g. prod, dev, test)	`demo`
`USERTOKEN`	arbitrary user-supplied token

According to the specification, semicolons and spaces in these fields are eliminated. We decided to replace them by underscores.

Authentication

This midPoint dockerization supports two authentication mechanisms.

Mechanism	Description
`internal`	Users are authenticated against midPoint repository. Login name to be used is the `name` property of the user, and the password is `credentials/password/value` property.
Mechanism	Description
`internal`	Users are authenticated against midPoint repository. Login name to be used is the `name` property of the user, and the password is `credentials/password/value` property.
`shibboleth`	Users are authenticated against Shibboleth IdP. This is ensured using Shibboleth SP (service provider) module for Apache httpd configured as reverse proxy for midPoint.

...

Environment variable	Meaning	Default value
`AUTHENTICATION`	Authentication mechanism to use	`internal`
`LOGOUT_URL`	URL to be used for logout (used for Shibboleth authentication)	`https://localhost:8443/Shibboleth.sso/Logout`
`SSO_HEADER`	Shibboleth attribute to be used as a login identifier. It is matched against `name` property of the user when logging in. When changing it, do not forget to change your Shibboleth IdP configuration as well as midPoint's `shibboleth2.xml` configuration file.	`uid`

Besides variables, the following secrets and configs are used for Shibboleth-based authentication.

Note that besides these variables you have to provide the following files. They are necessary for the Shibboleth service provider module.

File	Description	Typical location in demonstration scenarios
`/etc/shibboleth/`

ItemKindMeaningLocation

idp-metadata.xml

config

	Metadata related to Shibboleth identity provider	`configs-and-secrets/midpoint/shibboleth/idp-metadata.xml`
`/etc/shibboleth/shibboleth2.xml`

config

	Service provider configuration	`configs-and-secrets/midpoint/shibboleth/shibboleth2.xml`
`/etc/shibboleth/sp-cert.pem`

config

Service provider

certificate

certificates file configs-and-secrets/midpoint/shibboleth/sp-cert.pem

And the following Docker secrets are to be provided:

Secret	Description	Typical location in demonstration scenarios
`mp_sp-`

m_sp-

key.pem

secret

Service provider private key configs-and-secrets/midpoint/shibboleth/sp-key.pem

Other

Other aspects can be configured using the following variables and Docker secrets or configs.

KEYSTOREPASSWORD_FILE

Environment variable	Meaning	Default value
`MP_MEM_MAX`	The limit for Java help heap memory (`-Xmx` setting)	2048M
`MP_`	`MEM_INIT`	The initial amount of Java heap memory (`-Xms` setting)	1024M
`MP_JAVA_OPTS`	Any other Java options to be passed to midPoint
`MP_KEYSTORE_PASSWORD_FILE`	File (e.g. holding a docker secret) that contains the password for the midPoint keystore	File (e.g. holding a docker secret) that contains the password for the midPoint keystore	`/run/secrets/mmp_keystore_password.txt`
`MP_DIR`	midPoint home directory. Do not change until absolutely necessary, as the change might break many things.	`/opt/midpoint`

Other configs/secrets files that are necessary are:

Item

Kind

	Meaning	Location

m_keystore_password.txtsecretJava keystore password used by midPoint e.g. to encrypt sensitive information stored in the repository.configs-and-secrets/midpoint/application/keystore_password.txtm_host-key.pemsecretPrivate key for Apache HTTPSconfigs-and-secrets/midpoint/httpd/host-key.pemhost-cert.pemconfigCertificate for Apache HTTPSconfigs-and-secrets/midpoint/httpd/host-cert.pem

...

In order to quickly verify the Shibboleth integration feature of the standard midPoint container we have provided a sample Shibboleth composition in demo/shibboleth directory. It contains a Shibboleth IdP container (idp) and an LDAP directory container (directory). They are to be started independently on midPoint.

Here we show how:

Starting Shibboleth containers

Code Block

language	bash

$ cd demo/shibboleth
$ docker-compose up

Starting midPoint containers

Code Block

language	bash

$ cd midpoint
$ env AUTHENTICATION=shibboleth docker-compose up

Logging in

Use https://localhost:8443/midpoint URL as before. This time you will be redirected to Shibboleth login screen where you enter username of administrator and a password of password.

Image Removed

...

`/etc/pki/tls/certs/host-cert.pem`	Host certificate for Apache httpd	`configs-and-secrets/midpoint/httpd/host-cert.pem`
`/etc/pki/tls/certs/cachain.pem`	Certificate chain for Apache httpd	`configs-and-secrets/midpoint/httpd/host-cert.pem`

And the following Docker secrets are to be provided:

Item	Kind	Meaning	Location
`mp_host-key.pem`	secret	Private key for Apache httpd	`configs-and-secrets/midpoint/httpd/host-key.pem`
`mp_keystore_password.txt`	secret	Java keystore password used by midPoint e.g. to encrypt sensitive information stored in the repository.	`configs-and-secrets/midpoint/application/keystore_password.txt`

Anchor
repository-demo
repository-demo
Alternative repository demonstration

...

Page tree

Versions Compared

Old Version 32

New Version 33

Key

Repository

Repository

Authentication

Logging

Authentication

Other

Starting Shibboleth containers

Starting midPoint containers

Logging in

Anchor
repository-demo
repository-demo
Alternative repository demonstration

Page tree

Page History

Versions Compared

Old Version 32

New Version 33

Key

Repository

Repository

Authentication

Logging

Authentication

Other

Starting Shibboleth containers

Starting midPoint containers

Logging in

Anchorrepository-demorepository-demoAlternative repository demonstration

Anchor
repository-demo
repository-demo
Alternative repository demonstration