Infrastructure
ActiveMQ Client Configuration
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can connect to an external ActiveMQ service using TLS/SSL.
Message Broker URL
Set the URL for the ActiveMQ message broker. Example:
ssl://my-message-broker:61616
Azure Service Bus
Plugin: nevisadmin-plugin-nevisidm
Configures a nevisIDM Instance to publish events into Azure Service Bus queues.
Queues can be reused, for example for handling time-based and other failures,
Dead Letter Queue and Expiry Queue pointed to the same Remote Queue with the same AzureServiceBusRemoteQueue pattern.
Remote Provisioning Queue
Remote Azure Service Bus Queue to which provisioning messages should be sent.
Remote Expiry Queue
Remote Azure Service Bus Queue to which Expiry messages should be sent.
Messages in Expiry Queue are those messages which validTo time has passed without successful receive action and without failing for other reason.
For further reference check NevisIdm Technical documentation > Configuration > Components > Provisioning module > Provisioning providers.
Remote Dead Letter Queue
Remote Azure Service Bus Queue to which Dead Letter messages should be sent.
Dead letter messages are those messages which are not in the expiryQueue and their delivery was unsuccessful.
For further reference check NevisIdm Technical documentation > Configuration > Components > Provisioning module > Provisioning providers.
Trust Store
Assign a trust store which provides the Microsoft Azure TLS Issuing CA 01 certificate.
You can access the Host name with your browser by adding https:// in front,
download the CA certificate, and then use a PEM Trust Store to provide it.
Azure Service Bus Remote Queue
Plugin: nevisadmin-plugin-nevisidm
Configures an Azure Service Bus connection-string for Azure Service Bus pattern to use.
Host Name
Enter the complete Host name of the Service Bus as shown in the Azure portal.
Example: my-service-bus-name.servicebus.windows.net
Shared Access Policy
Enter the Policy that shall be used to connect.
Also known as: SAS Policy, Shared access policy
Primary Key
Enter the Primary Key of the Policy as shown in the Azure portal.
Queue
Enter the name of a queue.
Generic Deployment
Plugin: nevisadmin-plugin-base
Use the advanced pattern for the following use cases:
- Deploy files and scripts for your own custom component or application.
- Modify remote system configuration files.
- Patch files generated by other nevisAdmin 4 patterns (not recommended).
The pattern cannot be used when deploying to Kubernetes.
Note that the third option is not recommended. Instead, please explore the various Generic patterns which can configure many low-level options. If you cannot find a solution, please open a Nevis Support ticket. Support may be able to provide an alternative, or can create a product improvement request.
Path
Absolute path of a directory on the target host(s) where the files will be deployed to. The command will run from the same path.
nevisAppliance targets only: if the files must be persisted across reboots, use a file name
or path listed in the /etc/rwdisk.conf file on the nevisAppliance target host.
The path must not point into a directory (potentially) managed by a nevisAdmin 4 Instance Pattern.
Thus, it is not possible to directly overwrite files generated by other patterns. See Command
and Command: Execution File Triggers for an alternative solution to overcome this limitation.
Allowed Paths:
/tmp/generic-deployment/var/opt/<directory>
Example:
/tmp/generic-deployment/patch01/
Path: Delete Unknown Files
If enabled, all files in the directory (Path property) that are not specified under Files are deleted.
If you enable this property your files must be in one of the following directories or subdirectories:
/var/opt/tmp/home
Files
Upload the files which will be copied into the Path.
To upload files into subdirectories within Path, add a single .zip file with files and directories. Unpacked files will have Owner and Group applied. Note: If multiple files are uploaded, any .zip file is deployed as is, without being extracted.
It is not supported to overwrite files generated by other patterns. See also Path above.
Template Parameters
Define Template Parameters.
Examples:
smtp: smtp.siven.ch
These parameters can be used in:
- uploaded files matching an expression specified in the
Template Filesproperty - the value of the
Pathproperty - the value of the
Commandproperty
The expression formats are:
${param.<name>}:
namefound: parameter value is used.namemissing: expression is not replaced.
${param.<name>:<default value>}:
namefound: parameter value is used.namemissing: default value will be used.
In <default value> the character } must be escaped as \}.
Template Files
Expressions matching files in which to replace parameters.
If a single .zip file is unpacked, it is scanned for matching files as well.
Possible values are exact file names or file endings.
Example:
- my_script.sh
- *.txt
- *.properties
Owner
Owner of the directory at specified path. All files and subdirectories will have the same owner.
Group
Owner of the directory at path. All files and subdirectories will have the same owner.
Permissions: Owner
Read-write permissions for specified owner of the directory. All files and subdirectories (including unpacked from single .zip) will have the same permissions.
The executable bit will be set automatically for readable directories and for readable Executable Files.
Permissions: Group
Read-write permissions for specified group of the directory. All files and subdirectories (including unpacked from single .zip) will have the same permissions.
The executable bit will be set automatically for readable directories and for readable Executable Files.
Permissions: Other
Read-write permissions for all users of the directory. All files and subdirectories (including unpacked from single .zip) will have the same permissions.
The executable bit will be set automatically for readable directories and for readable Executable Files.
Executable Files
Expression to select files which shall have the executable flag.
Add exact file names or *.<ending>.
Example:
- myScript.sh
- *.py
Command
Bash shell expression which will be executed from the working directory Path as the deployment user (__connection_user variable in the inventory).
Example:
- ./my_script.sh
The command will run depending on the Command: Execution setting: always or conditional (e.g. onFileChange).
Note that with the onFileChange setting, the command is not automatically executed if you change it here.
Tip: Instead of specifying your shell instruction(s) here, add them as a separate script file into Files. For example, if the file name is
my_script.sh, enter ./my_script.sh as the Command. This way, the script will be re-executed each time you upload an updated script file
and deploy the project (if onFileChange command execution is configured below).
Command: Execution Phase
Defines when the command is executed. The files are always copied during the CONFIGURE phase.
Phases:
- CONFIGURE: Command runs after files have been uploaded, but before NEVIS instances are (re)started. Use e.g. when patching a NEVIS instance configuration file.
- ACTIVATE: Command runs when instances are (re)started. Use when deploying files or commands that are independent of NEVIS instances.
Command: Execution
Defines when or how often the command is executed.
Possible values are:
always: Execution during each deployment.onFileChange: Executed if an uploaded file under the specifiedPathhas changed.onFileTriggers: Executed if a file that is listed underCommand: Execution File Triggershas changed.onFileChange + onFileTriggers: Combining both options above.
Command: Execution File Triggers
Files deployed by other nevisAdmin 4 patterns that, when changed, trigger the script to be executed, even if the script and files itself do not change.
Example:
- /var/opt/nevisproxy/my_proxy/conf/navajo.xml
Hint:
This is useful for patching e.g. navajo.xml after generation. Note that during the next deployment, it will be reverted (if the nevisProxy Instance pattern is deployed as well)
and then patching will happen again.
Generic nevisAdapt Instance Settings
Plugin: nevisadmin-plugin-nevisadapt
Use this add-on pattern to set low-level properties
in configuration files of a nevisAdapt Instance.
nevisAdapt Properties
Add properties for nevisadapt.properties.
See nevisAdapt Reference Guide for details.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
For instance, you may configure nevisAdapt to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisadapt/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Generic nevisAuth Instance Settings
Plugin: nevisadmin-plugin-nevisauth
Use this add-on pattern to set low-level properties
in configuration files of a nevisAuth Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisAuth to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisauth/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Environment Variables
Add additional environment variables to the nevisAuth env.conf.
The standard environment variables RTENV_SECURITY_CHECK and JAVA_OPTS
will always be present in env.conf and cannot be overwritten using this setting.
Generic nevisDetect Instance Settings
Plugin: nevisadmin-plugin-nevisdetect
Use this add-on pattern to set low-level properties
in configuration files of a nevisDetect Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisDetect to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisdetect/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Generic nevisFIDO FIDO2 Instance Settings
Plugin: nevisadmin-plugin-fido2
Use this add-on pattern to set low-level properties
in configuration files of a nevisFIDO FIDO2 Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisFIDO to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisfido/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Configuration: nevisfido.yml
This setting provides a low-level way to add or overwrite configuration in nevisfido.yml.
Enter the configuration as it would appear in the nevisfido.yml using correct indentation.
Example:
management:
server:
port: 9089
healthchecks:
enabled: true
Generic nevisFIDO UAF Instance Settings
Plugin: nevisadmin-plugin-nevisfido
Use this add-on pattern to customize configuration files of a nevisFIDO UAF Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisFIDO to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisfido/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Configuration: nevisfido.yml
This setting provides a low-level way to add or overwrite configuration in nevisfido.yml.
Enter the configuration as it would appear in the nevisfido.yml using correct indentation.
Example:
management:
server:
port: 9089
healthchecks:
enabled: true
Generic nevisIDM Instance Settings
Plugin: nevisadmin-plugin-nevisidm
Use the add-on pattern to set low-level properties
in configuration files of an nevisIDM Instance.
nevisIDM Properties
Add properties for nevisidm-prod.properties.
See nevisIDM Reference Guide (chapter Configuration files) for details.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisIDM to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevisidm/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Generic nevisLogrend Instance Settings
Plugin: nevisadmin-plugin-nevisauth
Use the add-on pattern to set low-level properties
in configuration files of a nevisLogrend Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisLogrend to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevislogrend/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Generic nevisMeta Instance Settings
Plugin: nevisadmin-plugin-nevismeta
Use this add-on pattern to set low-level properties
in configuration files of a nevisMeta Instance.
Java Opts
Add additional entries to the JAVA_OPTS environment variable.
Use the expression ${instance} for the instance name.
For instance, you may configure nevisMeta to create a heap dump on out of memory as follows:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/var/opt/nevismeta/${instance}/log/
Be aware that this example will not work for Kubernetes as the pod will be automatically restarted on out of memory and the created heap dump files will be lost.
Generic nevisProxy Instance Settings
Plugin: nevisadmin-plugin-nevisproxy
You can assign the pattern to a nevisProxy Instance using Additional Settings.
Use to customize the main configuration files of the nevisProxy instance, including:
navajo.xmlbc.propertiesenv.conf
To configure logging, use nevisProxy Log Settings instead.
Configuration: navajo.xml
Customize the Navajo servlet container configuration (navajo.xml)
using XML constructs described in the nevisProxy Technical Documentation.
The root element <Service> must be provided.
Examples:
Increase the number of parallel requests (worker threads):
<Service>
<Server MaxClients="1000"/>
</Service>
Increase the maximum allowed request body size:
<Service>
<Server LimitRequestBody="10485760"/>
</Service>
To change the Server Timeout attribute (how long nevisProxy itself will wait before failing a request, default 30 seconds), use Request Timeout on the TCP Settings pattern assigned to a Virtual Host instead - see Request Timeout's help text for details.
When patching a certain Host, you have to provide the name.
Let's say you use the variable domain for Frontend Addresses in your Virtual Host.
You then have to use the expression ${var.domain} to patch the corresponding Host element.
Allow additional status codes by patching the Context element:
<Service>
<Engine>
<Host name="${var.domain}">
<Context additionalStatusCodes="207,210,242,422,423,424,449,456,540,541,543,544,545,456,549,552,560" />
</Host>
</Engine>
</Service>
Overrule the allowed HTTP methods:
<Service>
<Engine>
<Host name="${var.domain}">
<Context allowedMethods="ALL-HTTP" />
</Host>
</Engine>
</Service>
Overrule the server aliases for some.domain.com:
<Service>
<Connector name="some.domain.com" port="*" serverAlias="*.domain.com">
</Connector>
</Service>
It is possible to use the following placeholders:
${instance.id}: unique ID of thenevisProxy Instancepattern${instance.name}: name of the nevisProxy instance. For instance, use/var/opt/nevisproxy/${instance.name}to refer to the instance directory.
Limitations:
- customizing
Navajoelements is not supported - customizing
Host(or its child elements) requiresname
Configuration: bc.properties
Customize the low-level configuration (bc.properties)
using properties described in the nevisProxy Technical Documentation.
For instance, when request validation is enabled this requires a buffer and this buffer has to be big enough to store the entire request.
The following example increases the maximum size of the request buffer to 10 MB:
ch.nevis.navajo.request.BufferSize=10485760
You also may have to increase the maximum allowed request size.
See Configuration: navajo.xml for an example.
Note that increased buffer sizes may lead to increased demand of RAM and disk space.
When the required buffer exceeds ch.nevis.navajo.request.MemBufferSize
then nevisProxy will buffer to disk instead.
The demand caused by request buffers can be estimated as follows:
- RAM:
MaxClients*ch.nevis.navajo.request.MemBufferSize - disk:
MaxClients*ch.nevis.navajo.request.BufferSize
See Configuration: navajo.xml for a description of MaxClients.
Environment Variables
Add additional environment variables to the nevisProxy env.conf.
Each variable is written as KEY=VALUE followed by an export KEY line so it
becomes part of the nevisProxy process environment.
Keys defined by other patterns (for example PKCS11_PIN, SECUROSYS_PKCS11_CONF,
SECUROSYS_SECRETS_CONF and OPENSSL_CONF from the Securosys Key Store
pattern) must not be set here.
Template Parameters
Define Template Parameters.
Examples:
backend-host: backend.siven.ch
These parameters can be used in:
Configuration: navajo.xmlConfiguration: bc.properties
The expression formats are:
${param.<name>}:
namefound: parameter value is used.namemissing: expression is not replaced.
${param.<name>:<default value>}:
namefound: parameter value is used.namemissing: default value will be used.
In <default value> the character } must be escaped as \}.
nevisAdapt Database
Plugin: nevisadmin-plugin-nevisadapt
Configures nevisAdapt to use a MariaDB database.
Assign to nevisAdapt Instance as Database.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployments a database including tables must be set up before deployment.
Setup instructions can be found in the nevisAdapt technical documentation. See Database setup for details.
If you want to use an Oracle database you have to set Custom Connection URL,
instead of using the high-level settings, and upload the JDBC Driver.
Database Type
Choose between MariaDB, Oracle and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Database User
Provide the DB user name here.
Database Password
Provide the DB password here.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
JDBC Driver
Due to licensing, nevisAdapt cannot ship the JDBC driver to connect to Oracle databases, Therefore, those who want to use an Oracle database need to obtain and provide the Oracle JDBC driver on their own.
The .jar files can be downloaded from Oracle
Uploading any other .jar files containing JDBC drivers is possible as well.
Volume Claim
Due to licensing restrictions, we cannot ship any Oracle dependencies.
If you are using an Oracle database, are deploying to Kubernetes, and Database Management is enabled (complete or schema),
then you have to provide a Kubernetes volume containing an Oracle driver and client.
For more information, see Preparing Oracle Volume.
Enter the name of that volume here.
The volume will be mounted in the nevisadapt-dbschema image to set up and patch the database schema.
The volume will be mounted in the nevisadapt image to connect to the database.
Because of that, there is no need to upload a JDBC Driver.
Data Tablespace
Name of the data tablespace for the oracle database used for the Kubernetes migration. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Application Role
Name of the application role for the oracle database used for the Kubernetes migration. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Owner Role
Name of the owner role for the oracle database used for the Kubernetes migration. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Min Pool Size
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime
This setting controls the maximum lifetime of a connection in the pool.
After the specified lifetime, database connections are removed from the pool, closed, and reopened.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Flyway License Key
Please provide a licence key in case you would use the Flyway Teams Edition.
This is recommended only in case you would use an old database version (more than 5 years old). If you do not provide a licence key, the Flyway Community Edition will be used by default.
For more information about Flyway editions please visit this page Flyway.
Hikari Configuration Values
Enter custom values for Hikari datasource configuration.
Supported keys are described at HikariCP - GitHub.
The prefix spring.datasource.hikari. must not be included as it will be added automatically to each key.
The following keys should not be configured here as there are settings in the Connection Pool tab:
minimumIdlemaximumPoolSizeidleTimeoutmaxLifetime
If you still configure these keys, they will overrule the high-level settings.
Connection Parameters
Enter parameters for the DB connection string.
Enter 1 parameter per line.
Lines will be joined with &.
The default is:
useMysqlMetadata=true
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisAdapt Instance
Plugin: nevisadmin-plugin-nevisadapt
This pattern sets up a nevisAdapt instance.
For details check the nevisAdapt Documentation.
nevisAdapt implements adaptive, context-aware, and continuous authentication based on multiple attributes, like device information or geolocation. Together, these multiple attributes create a unique, digital user footprint.
In case of multi-host deployment, up to one nevisAdapt is supported per isolating line.
Port
Enter the port on which nevisAdapt will listen.
Database
Add a database connection reference pattern.
Required properties to be set in the connector pattern are as follows:
- JDBC Driver (Oracle or MariaDB)
- JDBC URL
- DB user/password
Log Settings
Assign nevisAdapt Log Settings to change the log configuration.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
SecToken Signer Trust Store
Assign the Trust Store provider for verifying the NEVIS SecToken. If no pattern is assigned the signer key will be provided by the nevisAdmin 4 PKI.
File Selection
Set a file code only if the provider is IP2LOCATION or MaxMind and also set the access token in that case.
Provide a file code that identifies the database file to be downloaded.
The supported values are:
upload- no update mechanism will be in place for custom uploads by default. Must be .csv/.CSV, up to 20MB.DB1BIN- commercial version, IP-CountryDB1BINLITE- free version, IP-CountryDB5BIN- commercial version, IP-Country-City-GPSDB5BINLITE- free version, IP-Country-City-GPSGeo2-City- MaxMind GeoIP2 City DatabaseGeoLite2-City- free version of the MaxMind GeoIP2 City Database
nevisAdapt does not provide any access tokens by default. They have to be generated after registration (in case of the commercial version, purchase).
You can find more information about the supported geolocation databases at the IP2LOCATION and MaxMind websites.
Mapping File Upload
Provide a file attachment for the IP-to-Location service to use.
Please consider uploading the file manually if its size exceeds 20MB, then adjust the path
ipToLocationMappingFile in nevisadapt.properties after deployment if needed.
With file upload, only the IP-Country database is supported, with fields listed as follows (CC is the 2-letter country code, no header row):
"IP range min (decimal)","IP range max (decimal)","CC","COUNTRY"
The file must adhere to the following formatting rules: all fields must be separated by commas and surrounded by double-quotes. The IP ranges should not intersect each other. File name must end with either .csv or .CSV.
If IP velocity analysis is required, it is handled through IP2LOCATION updates. No other provider is supported at this point. Please switch to either DB5BIN or DB5LITEBIN.
The IP-mapping file has to be updated regularly for the service to stay relevant.
Uploaded files are not updated by default.
We recommend setting up periodic update of IP geolocation and reputation mappings.
File Selection IPv6
Choose the IPv6 IP-to-location database source.
This setting is optional. If you set either IPv6 setting, you must also set this selector.
Supported values:
upload- use a custom CSV upload for IPv6 mapping.DB1BIN- commercial IPv6 database, IP-Country.DB1LITEBIN- free IPv6 database, IP-Country.DB5BIN- commercial IPv6 database, IP-Country-City-GPS.DB5LITEBIN- free IPv6 database, IP-Country-City-GPS.
IPv4 and IPv6 must use the same source type (upload or downloaded database), because schedule and token settings are shared.
Mapping File Upload IPv6
Provide an IPv6 mapping file upload.
Use this only when File Selection IPv6 is set to upload.
The file must:
- be a CSV file (
.csvor.CSV), - contain non-overlapping IPv6 ranges,
- follow the same CSV format requirements as the IPv4 upload.
If IPv6 upload is enabled, an IPv6 file must be provided for deployment.
Update Schedule
Pick the update frequency of the IP-to-location database.
Valid values:
disabled- no update mechanism will be triggered. Not recommended for productive environment.hourlydailyweeklymonthly
When selecting disabled, it's highly recommended having a mechanism in place for keeping the database file up-to-date.
We recommend setting up periodic update of IP geolocation and reputation mappings.
Download Token
Provide a secret download token for authentication.
Shared Storage Settings
Configure this to override the default configurations used for the shared storage in Kubernetes deployments. If you would use an existing shared volume please only set the claim name. This storage should support the ReadWriteMany access mode.
For more information regarding persistent volumes in Kubernetes please visit this page
IP Private Network Filter
nevisAdapt filters private addresses out by default because they do not provide any reputation related information. If you want to allow internal IP addresses for risk scoring, you can disable this feature.
The generated property will look like this:
nevisadapt.ipReputation.service.privateNetworkFilter=false
IP Private Network Country Code
When selected 'disabled' on IP Private Network Filter, the country code of the IP address will be assigned to this, regardless of the original input value. You can assign a Geolocation by country code using ISO 3166 alpha-2.
The generated property will look like this:
nevisadapt.ipReputation.service.privateNetworkCountryCode=<2-letter country code>
The default value is CH.
Apache Hostname Verifier
Enabling this option will set an Apache hostname verifier (which also handles certificate checks) instead of the default one.
Default: disabled (backwards compatibility)
Stage URL
Used by Nevis ID to reach the common geolocation mapping download location.
Mapping File Upload
Provide a file attachment for the IP reputation service to use.
Please consider uploading the file manually if its size exceeds 20MB, then adjust the path ipReputationMappingFile
in nevisadapt.properties after deployment if needed.
Every line should contain a single blacklisted IPv4 range in CIDR format:
A.B.C.D/E or A.B.C.D (A/B/C/D: [0-255]; E: [0-32])
The IP ranges should not intersect each other.
The IP-mapping file has to be updated regularly for the service to stay relevant. We recommend setting up periodic update of IP geolocation and reputation mappings.
Update Schedule
Pick the update frequency of the IP reputation database.
Valid values:
disabled- no update mechanism will be triggered. Not recommended for productive environment.hourlydailyweeklymonthly
When selecting 'disabled', it's highly recommended having a custom mechanism in place for keeping the database file up-to-date. We recommend setting up periodic update of IP geolocation and reputation mappings.
Update URL
Provide a download URL for the database file. The file is downloaded then moved over to the path defined above.
Apache Hostname Verifier
Enabling this option will set an Apache hostname verifier (which also handles certificate checks) instead of the default one.
Default: disabled (backwards compatibility)
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
nevisAdapt Observation Configuration
Used to assign a nevisAdapt Observation Cleanup Configuration pattern to configure
the time interval for cleaning up observation data.
This is an optional setting. Default values if nothing is set:
- Observation Timeframe:
60d - Trusted Cleanup Period:
1d - Untrusted Cleanup Timeframe:
12d
Suspicious Country Code List
Provide a list of two-letter ISO country codes of considerable risk.
Input method 1: Single line - comma-delimited
Input method 2: One country code entry per line
ISO code description can be found at: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
Proxy Host
Enter the host for the forward proxy if available.
Proxy Port
Enter the port of the forward proxy if available.
3182
Distrust Feedback Settings
Provide additional settings for defining the details of the distrust session mechanism:
- JWE key to generate new tokens with
- nevisAuth reference to distrust and terminate sessions there as well
- nevisProxy reference to build the distrust feedback URI
- action to take on received token
- token lifetime
- redirect URL after sending the token
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Device Cookie Name
Provide a name for the cookie that will be used as the volatile identification for a browser.
Leave this configuration empty if you want to keep the default value of DEVICE_COOKIE.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisAdapt Analyzer Configuration
Allows you to customize nevisAdapt Analyzer configuration.
nevisAdapt Shared Storage Settings
Plugin: nevisadmin-plugin-nevisadapt
Pattern to override the default shared storage settings used by nevisAdapt in Kubernetes deployments.
Claim Name
The name of the PersistentVolumeClaim.
For more information regarding persistent volumes in Kubernetes please visit this page
Storage Size
The size of the persistent volume. The minimum size is 1 gigabyte. We recommend using at least 4 gigabytes.
For example: 4GB
Storage Class
The name of the StorageClass. The selected storage should support ReadWriteMany access.
For example: azurefile
For more information regarding persistent volume types in Kubernetes please visit this page
Mount Path
The path where the volume will be mounted and used by the service.
For example: /var/opt/shared
For more information regarding persistent volumes in Kubernetes please visit this page
nevisAuth Database
Plugin: nevisadmin-plugin-nevisauth
Configures nevisAuth to use a MariaDB database for storing sessions and out-of-context data.
Assign to a nevisAuth Instance as Database.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployments a database including tables for sessions and out-of-context data must be set up manually before deployment. Setup instructions can be found in the nevisAuth technical documentation.
The log category for the session store is RemoteSessionStore.
Database Type
Choose between MariaDB and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Schema User
The user which will be used to connect to the database and create the schema (tables).
The database must have been created already (CREATE DATABASE)
and the user must have CREATE privileges for this database.
If not set, the database connection user will be used.
Example: schema-user
Schema User Password
The password of the user on behalf of the schema will be created in the database.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Password Type
Choose between:
automatic: behaves likecommandwhen the password starts with/opt/.command: use when the input is a command. Inesauth4.xmlthe prefixpipe://will be added.plain: take the password as-is.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
Key Store
Define the key store to use for 2-way HTTPs connections for DB endpoint.
This configuration only accept PEM Key Store pattern configuration.
Noted: This is an experimental configuration
Min Pool Size (Session Store)
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Min Pool Size (Out-of-Context Data Store)
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size (Session Store)
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Pool Size (Out-of-Context Data Store)
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Idle Time (Session Store)
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Idle Time (Out-of-Context Data Store)
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime (Session Store)
This setting controls the maximum lifetime of a connection in the pool.
After the specified lifetime, database connections are removed from the pool, closed, and reopened.
Max Lifetime (Out-of-Context Data Store)
This setting controls the maximum lifetime of a connection in the pool.
After the specified lifetime, database connections are removed from the pool, closed, and reopened.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Synchronize Sessions
Defines when sessions are stored to the remote session store.
after-successful-authentication
A session is stored to the remote session store once authentication has been completed successfully.
Use this mode when performance is critical, when the authentication flow is stateless (e.g. no GUI is shown), when there is only 1 nevisAuth instance, or in classic VM-based deployment scenarios.
always
Session are always stored to the remote session store.
This mode requires nevisAuth version 4.28.0.216 or newer.
We recommend this mode when you want to restart nevisAuth without user impact and for deployments to Kubernetes.
Typically, while a user is logging in, multiple requests are sent to nevisAuth.
If you configure multiple replicas of nevisAuth, the Kubernetes service may forward these requests to any of the replicas.
By selecting always, you ensure that all replicas can access the user's session during the authentication process.
recommended (default)
Uses always when deploying to Kubernetes and after-successful-authentication for classic, VM-based deployments.
Custom Attributes
Add or overwrite attributes of the RemoteSessionStore and RemoteOutOfContextDataStore XML elements.
Supported attributes are described in the Nevis documentation:
If you want to set an attribute only on one of the 2 elements use the prefix session: or oocd: as illustrated below.
Examples:
| Attribute | Value |
|---|---|
session:syncPullInitial | true |
session:reaperThreads | 5 |
session:storeUnauthenticatedSessions | false |
oocd:reaperPeriod | 120 |
Connection Parameters
Enter parameters for the DB connection string.
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Enter 1 parameter per line.
Lines will be joined with &.
Examples (from various Nevis components):
pinGlobalTxToPhysicalConnection=1
useMysqlMetadata=true
autocommit=0
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisAuth Instance
Plugin: nevisadmin-plugin-nevisauth
Represents a nevisAuth instance. The instance is named according to the pattern.
Hint for pattern renaming
When the 'Instance Name' property is not filled, the pattern uses the pattern's name as instance directory at the target host.
To rename the pattern, do the following:
- Rename the pattern in the GUI.
- Rename the instance directory and associated systemd files on the deployment hosts.
- Deploy.
In case step 2 is omitted the old instance is shut down during deployment.
For more information, see technical documentation: User Guide / Configuration Projects / Working with Patterns.
Port
Port the nevisAuth instance is listening on.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Log Settings
Add logging configuration for nevisAuth.
Database
By default, nevisAuth stores sessions and out of context data in memory.
In most setups you should use a database instead, and you should assign a nevisAuth Database pattern here.
In memory should be used only when there is only 1 line / pod of nevisAuth, or in a classic deployment where nevisProxy can ensure session-sticky load balancing towards nevisAuth.
Languages
Configure the language codes that shall be supported.
Each language code must be entered on a new line. By default, translations are provided for the following codes:
en: Englishde: Germanfr: Frenchit: Italian
nevisAuth uses the Accept-Language header sent by the browser to determine the user language.
In case this header is not available the first configured language code will be used as a default.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Default Backend Key Store
Assign the Key Store provider for outbound TLS connections. If no pattern is assigned a key store will be provided by the nevisAdmin 4 PKI.
Outbound Client Authentication
Controls whether nevisAuth presents a client certificate on outbound TLS connections.
automatic generates a client identity when a configured outbound target requires client authentication. required ensures that client authentication is used, preserving an explicitly configured key store and generating an implicit identity only when no key store is configured. disabled prevents client authentication and is rejected when a configured target requires it.
Default Backend Trust Store
Assign the Trust Store provider for outbound TLS connections. If no pattern is assigned a trust store will be provided by nevisAdmin 4 automatic key management.
Internal SecToken Signer Key Store
Assign a key store for signing the internal NEVIS SecToken.
This token is returned to nevisProxy and validated there. It should not be added to calls to applications.
If your applications need a NEVIS SecToken, assign a Nevis SecToken pattern to your applications.
If no pattern is assigned, the signer key material will be provided by automatic key management.
Internal SecToken Signer Trust Store
Assign a trust store to validate the signature of the internal NEVIS SecToken.
This is an advanced setting and it is usually not required to configure this.
If no pattern, an Automatic Key Store pattern, or a PEM Key Store,
is assigned to Internal SecToken Signer Key Store, then you do not have to configure this.
The configuration of nevisAuth will be generated correctly, based on the deployment type and scaling.
Configuration is required in classic VM deployment, when this instance is deployed to multiple hosts,
and the hosts have different key material in the Internal SecToken Signer Key Store.
Session Limit
Defines the maximum number of user sessions than may be created in this nevisAuth instance.
A nevisAuth session requires at least 10kb but the session can be much bigger when a user has many roles or multiple tokens are used.
Worker Threads
Number of threads to process incoming requests.
Session Eviction Mode
Controls how sessions are retained in memory and how expiry is handled when a nevisAuth Database is assigned.
| Scenario | Description |
|---|---|
| Legacy | Default, backward-compatible behavior. Sessions synced to the remote store remain in the local in-memory store for their full lifetime. The remote reaper deletes expired sessions from the database directly without firing termination events. |
| Consistency | The local reaper evicts synced sessions from memory. When sessions expire in the remote store, the remote reaper fires session termination events before bulk-deleting them. Recommended when running multiple nevisAuth instances with a shared remote session store and terminated session polling is enabled in nevisProxy. |
| Performance | The local reaper evicts synced sessions from memory, reducing the in-memory footprint. However, the remote reaper deletes expired sessions directly from the database without firing termination events. Suitable only when terminated session polling in nevisProxy is not required. |
The Consistency and Performance scenarios are only effective when a nevisAuth Database is assigned.
For more information, see Session Management.
Max Sessions Per Reaper Run
Maximum number of expired sessions to process per reaper run.
Only used when Session Eviction Scenario is set to Consistency.
Batch Size Per Reaper Run
Number of sessions loaded and processed per batch within a reaper run.
Must be between 1 and 1000. Smaller batches reduce memory pressure but require more database round-trips.
Only used when Session Eviction Scenario is set to Consistency.
Custom Dependencies
In case AuthStates uses custom AuthState classes upload the required JAR file(s) here.
Files will be deployed into the plugin directory of the nevisAuth instance.
Classpath Prefix
Enter directory paths to be added to the classPath of the AuthEngine.
The paths will be added as a prefix. Entries added by other patterns
(e.g. /opt/nevisidmcl/nevisauth/lib or /opt/nevisauth/plugin)
are preserved.
This is an advanced setting which should only be used
when working with custom AuthState classes.
Startup Probe Delay
Time to wait before checking Kubernetes readiness on startup.
You may have to increase this value if start of the nevisAuth service fails because of a failing readiness check.
Sets initialDelaySeconds of the Kubernetes startup probe.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Line Preference
This setting (together with the inventory) defines the order of nevisAuth endpoints in the connection string from nevisProxy.
nevisAuth stores unauthenticated sessions in memory.
In a classic deployment to VMs, even when a nevisAuth MariaDB Remote Session Store is configured,
sessions are synced to the DB only after successful authentication.
Thus, multi-step login flows require that requests for the same session are routed to the same nevisAuth endpoint.
nevisProxy uses a simple fail-over strategy. The first URL in the connection string for nevisAuth is always used, unless this instance is not available. This strategy works well when:
- there is only 1 nevisProxy instance
- there are 2 lines of nevisProxy but line 1 is active and line 2 is standby
- there is a session-sticky load-balancer in front of nevisProxy is session-sticky
The order of the connection string depends on the inventory. See also: Defining Lines and Fail-over Association
This strategy may fail in active / active setups when line groups are defined in the inventory.
In such setups you can set this drop-down to disabled to ensure that the order in the connection string is the same on all nevisProxy lines.
Start Timeout
Enter a timeout to wait for nevisAuth startup.
Set a higher value if nevisAuth takes longer to start.
This setting applies to classic VM-based deployment only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Connection Host:Port
Enter the host:port pair(s) which nevisProxy should use to connect to this nevisAuth instance.
This setting is required when the primary names of the nevisAuth hosts are not accessible by nevisProxy, which is sometimes the case in classic VM deployment, when working with multi-homed target hosts.
The server certificate provided by the Frontend Key Store must be valid
for all provided hosts names.
Bind Host:Port
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes nevisAuth listens on 0.0.0.0
and thus this setting is discouraged.
Propagate Session
Define the value of the AuthEngine attribute propagateSession.
enabled:trueis set which makes nevisAuth return the user's session to nevisProxy onAUTH_DONE.disabled:falseis set - nevisAuth does not return the session.
It is generally recommended to disable this feature and thus we
plan to change the default to disabled in a future release.
Session Index
Enables session indexing.
WARNING: Other patterns, such as nevisAdapt Instance may overrule this configuration.
This is required by ThrottleSessionsState.
Set Session Index Attribute if you need to index a non-default attribute.
Session Index Attribute
Enter the name of a session variable for the session index.
Differing Resource Startover
Define the value of the AuthEngine attribute differingResourceStartover.
enabled:trueis set.disabled:falseis set.
Do not change this unless you know what you are doing.
ID Pregenerate
Define the value of the idPregenerate attribute.
enabled:trueis set.disabled:falseis set.
Do not change this unless you know what you are doing.
Management Service
The nevisAuth Session Management REST endpoint can be called to terminate sessions.
The endpoint is enabled by default as it eases the integration of use cases provided by nevisAdapt.
The following element will be generated into the esauth4.xml:
<RESTService name="ManagementService" class="ch.nevis.esauth.rest.service.session.ManagementService"/>
As nevisAuth is typically not directly exposed to the internet (only via nevisProxy) and can only be reached using 2-way TLS, the endpoint does not increase the attack surface.
However, if you are sure that you do not need this endpoint, then you can opt out and select disabled here.
Server Configuration
Set Server Configuration properties (nevisauth.yml).
Examples:
server.max-http-header-size: 16384
SecToken Verification Cache Size
Configures the size of the nevisAuth SecToken verification cache for incoming SecTokens used by step-up and related flows.
The value is applied to the first generated KeyStore, which is typically DefaultKeyStore. It is used for internal SecToken verification and does not configure application signer KeyStores.
The product default is 4096 when this setting is not configured. Set the value to 0 or any negative number to disable the cache.
Custom Resources
Upload additional resources required by your configuration.
Uploaded files will be deployed into the conf folder of the nevisAuth instance.
Shared Groovy Scripts
Upload shared Groovy scripts used in your authentication steps.
You can use the expression ${var.<name>} inside your scripts to refer to an inventory variable.
How the value of a variable is generated into the script depends on the variable content:
Scalar variables will be generated as-is. This means the variable expression has to be within a Java String (') or a Groovy GString (").
YAML variables of type sequence will be generated as a Groovy list.
For instance, let's assume you have the following variable in your inventory:
my-sequence-var:
- some-entry
- another-entry
In your script you may use the expression as follows:
def myList = ${var.my-sequence-var}
The following will be generated:
def myList = ["some-entry", "another-entry"]
Inventory variables containing a YAML mapping are not supported yet.
Uploaded files will be deployed to the conf/groovy folder of the nevisAuth instance.
Additional Settings
Assign add-on patterns to customize the configuration of nevisAuth.
nevisDataPorter Instance
Plugin: nevisadmin-plugin-nevisdp
The pattern represents a nevisDataPorter instance. The instance is named according to the pattern.
Status Port
The port on which Azure is making request to get liveness and health status from the NevisDP management port.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Configuration
The dataporter.xml must be uploaded here.
In the XML, you can use ${var. expressions to reference inventory variables.
For instance, use ${var.a} to reference an inventory variable named a.
The value of the inventory variable must be a scalar.
Click Download Configuration Template to get started.
Log Settings
Add logging configuration for nevisDataPorter.
Key Store
Assign a key store which shall be used for outbound (2-way) TLS connections to nevisIDM. If no pattern is assigned no key store will be generated.
For nevisDataPorter to use the key store,
the following expressions should be used inside the dataporter.xml file:
${idm.keystore}
${idm.keystore.password}
Example configuration:
<object type="NevisIDMConnectionPool" name="adminService">
<dp:paraVal name="endpoint" value="${cfg.idmEndpoint}"/>
<dp:paraVal name="loginMode" value="proxyCert"/>
<dp:paraMap name="sslSettings">
<value name="javax.net.ssl.keyStore" value="${idm.keystore}"/>
<value name="javax.net.ssl.keyStorePassword" value="${idm.keystore.password}"/>
...
</dp:paraMap>
</object>
Trust Store
Assign a trust store which shall be used for outbound TLS connections to nevisIDM. If no pattern is assigned no trust store will be generated.
For nevisDataPorter to use the trust store,
the following expressions should be used inside the dataporter.xml file:
${idm.truststore}
${idm.truststore.password}
Example configuration:
<object type="NevisIDMConnectionPool" name="adminService">
<dp:paraVal name="endpoint" value="${cfg.idmEndpoint}"/>
<dp:paraVal name="loginMode" value="proxyCert"/>
<dp:paraMap name="sslSettings">
<value name="javax.net.ssl.trustStore" value="${idm.truststore}"/>
<value name="javax.net.ssl.trustStorePassword" value="${idm.truststore.password}"/>
...
</dp:paraMap>
</object>
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Custom JAR Files
Upload custom JAR files to handle specialized logic.
Custom Resources Base Directory
Configure the base directory for uploaded Custom Resources.
Enter a path relative to the instance directory, such as conf or import.
Absolute paths and nested paths are not supported.
Custom Resources
Upload additional resources here.
For instance, you may upload files used by your data sources in the Configuration.
nevisAdmin generation time expressions (e.g. ${var.name}) are not supported here.
Java Opts
Upload additional jvm configuration here.
Example of a JVM configuration file
-Dcom.sun.jndi.ldap.connect.pool.debug=all
nevisDetect Admin Instance
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can set up the administration service for nevisDetect.
TCP Service Port
Enter the port on which nevisDetect Admin service will listen.
nevisDetect Message Queue
Add references (at least one) for the patterns configuring Java Messaging Service. In case of Kubernetes deployment, only one configuration is allowed.
Two different options are allowed at this time:
nevisDetect Message Queue Instance- deployment pattern for a dedicated MQ componentActiveMQ Client Configuration- connect to an external ActiveMQ service via SSL
WARNING: In case of Kubernetes deployment, only ActiveMQ Client Configuration is supported.
Log Settings
Assign nevisDetect Log Settings to change the log configuration.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
SecToken Signer Trust Store
Assign the Trust Store provider for verifying the NEVIS SecToken. If no pattern is assigned the signer key will be provided by the nevisAdmin 4 PKI.
Message Queue Client Key Store
Used when simple or mutual (2-way) HTTPs is configured. If no pattern is assigned here automatic key management will provide the key store.
Message Queue Client Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisDetect Core Instance
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can set up the plugin administration for nevisDetect.
TCP Service Port
Enter the port on which nevisDetect Core will listen.
nevisDetect Persistency
Add reference for a nevisDetect Persistency Instance pattern.
nevisDetect Message Queue
Add reference for the pattern providing Java Messaging Service.
Two different options are allowed at this time:
nevisDetect Message Queue Instance- deployment pattern for a dedicated MQ componentActiveMQ Client Configuration- connect to an external ActiveMQ service via SSL
WARNING: In case of Kubernetes deployment, only ActiveMQ Client Configuration is supported.
Risk Plugins
List of Risk Plugins that are loaded by this nevisDetect Core component
Log Settings
Assign nevisDetect Log Settings to change the log configuration.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Message Queue Client Key Store
Used when simple or mutual (2-way) HTTPs is configured. If no pattern is assigned here automatic key management will provide the key store.
Message Queue Client Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisDetect Feature Correlator Instance
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can set up the feature correlation within nevisDetect to be able to correlate the requests coming from nevisProxy.
See also nevisDetect Feature Correlator.
TCP Service Port
Enter the port on which nevisDetect Feature Correlator will listen.
nevisDetect Persistency
Add reference for a nevisDetect Persistency Instance pattern.
nevisDetect Message Queue
Add reference for the pattern providing Java Messaging Service.
Two different options are allowed at this time:
nevisDetect Message Queue Instance- deployment pattern for a dedicated MQ componentActiveMQ Client Configuration- connect to an external ActiveMQ service via SSL
WARNING: In case of Kubernetes deployment, only ActiveMQ Client Configuration is supported.
Log Settings
Assign nevisDetect Log Settings to change the log configuration.
Content-Type Restriction
Apply restriction based on request header Content-Type
Sub-path Restriction
Set to apply this pattern on some sub-paths only.
Sub-paths must be relative (e.g. not starting with /)
and will be appended to the frontend path(s) of the virtual host (/)
or applications this pattern is assigned to.
Sub-paths ending with / are treated as a prefix,
otherwise an exact filter-mapping will be created.
The following table provides examples to illustrate the behavior:
| Frontend Path | Sub-Path | Effective Filter Mapping |
|---|---|---|
/ | secure/ | /secure/* |
/ | accounts | /accounts |
/ | api/secure/ | /api/secure/* |
/ | api/accounts | /api/accounts |
/app/ | secure/ | /app/secure/* |
/app/ | accounts | /app/accounts |
/app/ | api/secure/ | /app/api/secure/* |
/app/ | api/accounts | /app/api/accounts |
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Message Queue Client Key Store
Used when simple or mutual (2-way) HTTPs is configured. If no pattern is assigned here automatic key management will provide the key store.
Message Queue Client Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisDetect Message Queue Instance
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can set up an ActiveMQ service for nevisDetect.
Message Broker Name
The name for the broker to configure ActiveMQ with.
Server Port
Enter the port on which nevisDetect MQ will listen.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisDetect Persistency Instance
Plugin: nevisadmin-plugin-nevisdetect
Using the pattern, you can set up the persistency service for nevisDetect.
TCP Service Port
Enter the port on which nevisDetect Persistency will listen.
Database
Add a database connection reference pattern.
Required properties to be set in the connector pattern are as follows:
- JDBC Driver (Oracle or MariaDB)
- JDBC URL
- DB user/password
nevisDetect Message Queue
Add reference for the pattern providing Java Messaging Service.
Two different options are allowed at this time:
nevisDetect Message Queue Instance- deployment pattern for a dedicated MQ componentActiveMQ Client Configuration- connect to an external ActiveMQ service via SSL
WARNING: In case of Kubernetes deployment, only ActiveMQ Client Configuration is supported.
Log Settings
Assign nevisDetect Log Settings to change the log configuration.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
SecToken Signer Trust Store
Assign the Trust Store provider for verifying the NEVIS SecToken. If no pattern is assigned the signer key will be provided by the nevisAdmin 4 PKI.
Message Queue Client Key Store
Used when simple or mutual (2-way) HTTPs is configured. If no pattern is assigned here automatic key management will provide the key store.
Message Queue Client Trust Store
Reference a trust store provider pattern or leave empty to manage the trust store with nevisAdmin.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
Enter a custom host name to listen on.
This setting is relevant in classic VM deployment, when working with multi-homed target hosts.
In Kubernetes the component listens on 0.0.0.0
and thus this setting is discouraged.
Additional Settings
Assign an add-on pattern to customize the configuration.
nevisFIDO FIDO2 Database
Plugin: nevisadmin-plugin-fido2
Configures nevisFIDO to use a MariaDB database for storing sessions.
Assign to nevisFIDO FIDO2 Instance as Database.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployment you have to provide an empty database and a schema user. The schema user is used by nevisFIDO to populate the database during startup.
Setup instructions can be found in the nevisFIDO technical documentation.
Database Type
Choose between MariaDB and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Schema User
The user which will be used to connect to the database and create the schema (tables).
The database must have been created already (CREATE DATABASE)
and the user must have CREATE privileges for this database.
Example: schema-user
Schema User Password
The password of the user on behalf of the schema will be created in the database.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
Key Store
Define the key store to use for 2-way HTTPs connections for DB endpoint.
This configuration only accept PEM Key Store pattern configuration.
Noted: This is an experimental configuration
Min Pool Size
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of connections allowed in the connection pool.
Default value is 10.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime
Configure the maximum time that a session database connection remains in the connection pool.
A high value improves the performance, but it should be lower than the connection idle timeout of the database (parameter wait_timeout in MariaDB).
If not specified, the default value is 10 minutes. If no time unit is provided, seconds will be used.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Connection Timeout
Defines the maximum time that nevisFIDO waits for the connection to receive a response from the database.
Default is 30 seconds.
Connection Parameters
Enter parameters for the DB connection string.
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Enter 1 parameter per line.
Lines will be joined with &.
Examples (from various Nevis components):
pinGlobalTxToPhysicalConnection=1
useMysqlMetadata=true
autocommit=0
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisFIDO FIDO2 Instance
Plugin: nevisadmin-plugin-fido2
Sets up a nevisFIDO instance with support for FIDO2.
Port
Port the nevisFIDO UAF Instance is listening on.
Status Port
This port is used to check if the instance is up after deployment.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
SecToken Signer Trust Store
Assign a trust store for SecToken verification.
Database
The database where the nevisFIDO sessions will be stored can be configured here. If no pattern is assigned, the sessions will be stored in memory.
Log Settings
Assign nevisFIDO Log Settings to change the log configuration.
User Name
Configure what is expected as username in incoming API calls.
Choose between extId and loginId.
Display Name Source
Defines the attribute of the user that will be populated into the user.name property in the PublicKeyCredentialCreationOptions object that nevisFIDO sends to the FIDO2 client during the Registration ceremony.
Some browsers choose this user.name property to display to the user when they prompt for user interaction (as opposed to user.displayName).
Supported values are loginId, displayName, email and username - this latter does not correspond strictly to a nevisIDM user property, but instead is the same username what nevisFIDO received in the ServerPublicKeyCredentialCreationOptionsRequest object.
The default is loginId.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected. Generatesserver.tls.client-auth=required.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted. Generatesserver.tls.client-auth=requested.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail. Generatesserver.tls.client-auth=disabled.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Relying Party Name
Enter a name for the relying party.
This name is displayed by the user agent when performing a FIDO 2 registration or authentication.
Relying Party ID
Enter a base domain for all Relying Party Origins.
Example: example.com
Relying Party Origins
Enter all URLs from where FIDO 2 registration and authentication is invoked.
Example: https://www.example.com
nevisFIDO will use this information to check the Origin header of incoming REST calls.
URLs must be entered without a path.
URLs must have a common base domain which will be used as the ID for the relying party.
For Android Applications using the non-WebauthN standard compliant Origins enter the origin in the format android:apk-key-hash:<your-apk-key-hash>.
Metadata Location
Choose how to provide the metadata for allowed FIDO2 authenticators.
Select remote to fetch metadata from a remote service.
The URL(s) are defined by the setting Metadata Service URL(s) and you can customize them there.
We recommend using the official service provided by the FIDO Alliance.
The metadata BLOB is signed, and its signing chain is not trusted by default,
so you also have to configure Metadata Service Trust Store.
Note that this trust store holds the root certificate of the metadata BLOB signing chain,
not the TLS certificate of the endpoint.
If you need to use a proxy to connect to this service, you have to set at least the Proxy Address.
If your proxy requires authentication, you also have to set Proxy User and Proxy Password.
When local is selected, you will be asked to upload your metadata via Local Metadata.
When none is selected, no metadata will be configured. This means all authenticators will be allowed.
The option compat allows for a seemless upgrade.
In compat mode the configuration depends on the setting Local Metadata (called Allowed Authenticators in previous versions).
When Local Metadata is provided, compat behaves like local. Otherwise, it behaves like none.
See FIDO2 Authenticator Metadata for details on the metadata sources and the trust anchors used to validate them.
Metadata Service URL(s)
Here you can configure a list of FIDO2 metadata service URLs.
In normal scenarios you most likely want to use the official metadata endpoint of the FIDO alliance.
The endpoint certificate for this HTTPS connection is validated against the default trust store of the Java runtime.
Check our configuration guide for additional information.
Metadata Service Trust Store
If Metadata Location is set to remote, you have to configure this trust store.
Assign a PEM Trust Store and upload the root certificate of the metadata BLOB signing chain there.
This trust store provides the trust anchors used to validate the signing chain of the downloaded metadata BLOB. It is not used for the TLS connection to the endpoint: the endpoint certificate is validated against the default trust store of the Java runtime.
For the official FIDO Alliance Metadata Service this is a GlobalSign root certificate. The FIDO
Alliance migrated the signing chain from GlobalSign Root CA - R3 to GlobalSign Root R46, which
you can download from https://valid.r46.roots.globalsign.com/.
A trust store may contain several root certificates and all of them are used as trust anchors, so
you can keep the previous root alongside the new one during the transition.
Be aware that the signing root may change over time, independently of the endpoint certificate.
See FIDO2 Authenticator Metadata for details.
Proxy Address
Here you can configure a proxy URL through which requests to the metadata service will be routed.
It is useful in environments where direct internet access is restricted or security policies mandate proxy usage.
By default, no proxy is set.
Proxy User
This setting defines the username required for authentication with the configured proxy.
It should be provided if the proxy service requires authentication.
By default, this setting is not set.
Proxy Password
This setting defines the password used alongside the proxy username for authentication purposes.
It must be defined if the proxy server requires password-based authentication.
By default, this setting is not set.
Local Metadata
Here you can configure which authenticators are allowed.
Upload the FIDO2 authenticator metadata file here.
This setting is used only when Metadata Location is set to local.
Usage of local metadata is recommended when Allowed Authenticators is enabled.
Proceed as follows:
- Download the official FIDO Alliance Metadata file (JWT) from the FIDO Alliance Metadata Service.
- Decode the downloaded JWT.
- Copy out the complete metadata statements of the desired authenticators into a new JSON file.
- (optional) Remove the optional entries to “slim down” the metadata entry, only required entries are
aaguidandattestationRootCertificates. - Safe the JSON file and upload it here.
You can find more information in our FIDO2 Concept and Integration Guide.
Restrict Authenticators
By default, all authenticators that fulfill the requirements are allowed.
Here you can restrict which authenticators are allowed based on metadata.
If you select enabled here, it is typically required to provide customized metadata.
Thus, you should set the Metadata Location to local and upload the required metadata file.
nevisIDM
Assign a nevisIDM Instance or nevisIDM Connector pattern.
Use nevisIDM Connector only when the nevisIDM instance is not setup by the same nevisAdmin 4 project.
When using nevisIDM Connector you have to use non-automatic key management.
Client
Enter the extId of the nevisIDM Client.
Only 1 client is supported.
Key Store
Assign a key store to be used for the 2-way TLS connection to nevisIDM.
If no pattern is assigned an automatic key store will be generated.
This requires automatic key management to be enabled in the inventory.
Further, the pattern assigned to nevisIDM must be a nevisIDM Instance
which uses an automatic trust store for the Frontend Trust Store.
Note that it is required that the certificate used by nevisFIDO to connect to nevisIDM
is uploaded as a certificate credential for the nevisfido technical user.
This is done automatically when deploying to Kubernetes and using automatic key management
on both sides. In any other case, this step has to be done manually.
Trust Store
Assign the trust store for validating the nevisIDM endpoint.
The trust store should contain the certificate of the CA that has issued the server certificate.
If no pattern is assigned an automatic trust store will be generated. This requires automatic key management to be enabled in the inventory.
In that case the pattern assigned to nevisIDM must be a nevisIDM Instance pattern
which uses an automatic key store for the Frontend Key Store.
User Presence Verification Timeout
Maximum time that a FIDO2 client has to send the response in a ceremony where user-verification is required.
Default value is 5 minutes.
No User Presence Verification Timeout
Maximum time that a FIDO2 client has to send the response in a ceremony where user-verification is not required.
Default value is 2 minutes.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Signature Algorithms
Configure the allowed signature algorithms.
Recommended by IANA:
ES256: ECDSA using P-256 and SHA-256 (allowed by default)ES384: ECDSA using P-384 and SHA-384ES512: ECDSA using P-521 and SHA-512EdDSA: Edwards-curve Digital Signature Algorithm (allowed by default)
Not recommended:
RS384: RSASSA-PKCS1-v1_5 using SHA-384RS256: RSASSA-PKCS1-v1_5 using SHA-256RS512: RSASSA-PKCS1-v1_5 using SHA-512RS1: RSASSA-PKCS1-v1_5 with SHA1 (deprecated)
Registration Authorization
Configure if a SecToken is required to perform operations associated with registration.
Note that the Groovy script used by FIDO2 Onboarding pattern adds a SecToken to calls of the nevisFIDO REST API.
User Presence Requirement
Defines the user presence requirement of nevisFIDO during FIDO2 authentication and onboarding.
This setting is closely related to the user verification requirement, which is expressed in the options request (/nevisfido/fido2/attestation/options).
Both the FIDO2 Authentication and FIDO2 Onboarding pattern have a setting User Verification for this.
User verification is the process of verifying the user through biometric recognition or by manually entering a PIN, while a user presence test is a simple interaction, such as pressing a button, to confirm human presence.
Together, the user presence and user verification requirements define the characteristics of the required authorization gesture from the user during the ceremony.
Cancel Endpoint
Enable or disable the POST /nevisfido/cancel endpoint, which allows cancelling ongoing mobile authentication operations.
Only enable this if the endpoint is secured, for example via a nevisProxy Virtual Host with an Authentication Realm.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Additional Settings
Assign add-on patterns to customize the configuration of nevisFIDO.
nevisFIDO UAF Database
Plugin: nevisadmin-plugin-nevisfido
Configures nevisFIDO to use a MariaDB database for storing sessions.
Assign to nevisFIDO UAF Instance as Database.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployment you have to provide an empty database and a schema user. The schema user is used by nevisFIDO to populate the database during startup.
Setup instructions can be found in the nevisFIDO technical documentation.
Database Type
Choose between MariaDB and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Schema User
The user which will be used to connect to the database and create the schema (tables).
The database must have been created already (CREATE DATABASE)
and the user must have CREATE privileges for this database.
Example: schema-user
Schema User Password
The password of the user on behalf of the schema will be created in the database.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
Key Store
Define the key store to use for 2-way HTTPs connections for DB endpoint.
This configuration only accept PEM Key Store pattern configuration.
Noted: This is an experimental configuration
Min Pool Size
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of connections allowed in the connection pool.
Default value is 10.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime
Defines the maximum time that a session database connection remains in the connection pool.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Connection Timeout
Defines the maximum time that nevisFIDO waits for the connection to receive a response from the database.
Default is 30 seconds.
Connection Parameters
Enter parameters for the DB connection string.
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Enter 1 parameter per line.
Lines will be joined with &.
Examples (from various Nevis components):
pinGlobalTxToPhysicalConnection=1
useMysqlMetadata=true
autocommit=0
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisFIDO UAF Instance
Plugin: nevisadmin-plugin-nevisfido
Represents a nevisFIDO instance which has been set up for FIDO UAF use cases.
Further information about nevisFIDO can be found in the nevisFIDO Technical Documentation.
Port
Port the nevisFIDO UAF Instance is listening on.
Status Port
This port is used to check if the instance is up after deployment.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Log Settings
Assign nevisFIDO Log Settings to change the log configuration.
Frontend Address
Enter the address of the Virtual Host where the services of this instance are exposed.
Enter the address without any path component.
Example:
https://example.com
If no address is provided, the pattern tries to automatically determine a value based on the Virtual Host patterns,
that are associated with this instance through patterns for out-of-band use-cases.
The entered value is used to calculate:
- AppID
- Dispatch payload
The dispatch payload informs the mobile device where to access nevisFIDO for the following use cases:
SecToken Signer Trust Store
Assign a trust store for SecToken verification.
Database
The database where the nevisFIDO sessions will be stored can be configured here. If no pattern is assigned, the sessions will be stored in memory.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected. Generatesserver.tls.client-auth=required.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted. Generatesserver.tls.client-auth=requested.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail. Generatesserver.tls.client-auth=disabled.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Facets
Facets are required configuration for mobile authentication scenarios.
The FIDO AppID and Facet Specification defines facets as identities of a single logical application across various platforms.
The following wildcard facet IDs are included for ease of use, to speed up integration of the Nevis Access App or Nevis Mobile Authentication SDK:
android:apk-key-hash:*,
ios:bundle-id:*
The wildcard facet ID entries are compatible with integration flavor Access Apps or debug flavor mobile SDKs. Production Access Apps or release mobile SDKs do not accept wildcard facet ID entries. If you want to use one of the Nevis Mobile Authentication SDK example applications with the release SDK, you will need to add one or multiple of the following facetID entries:
android:apk-key-hash:ch.nevis.mobile.authentication.sdk.android.exampleandroid:apk-key-hash:ch.nevis.mobile.authentication.sdk.flutter.exampleandroid:apk-key-hash:ch.nevis.mobile.authentication.sdk.react.exampleios:bundle-id:ch.nevis.mobile.authentication.sdk.ios.exampleios:bundle-id:ch.nevis.mobile.authentication.sdk.flutter.exampleios:bundle-id:ch.nevis.mobile.authentication.sdk.objc.proxy.exampleios:bundle-id:ch.nevis.mobile.authentication.sdk.react.example
For production deployment you have to replace the default and add your own facets for your iOS or Android applications. The following documentation provides additional information:
- For Access Apps, refer to the FacetID Calculation documentation.
- For the mobile SDK, refer to the FacetID chapter in the configuration section.
Policies
A FIDO UAF Policy defines which authenticators can be used during registration or authentication.
Each configuration file has to contain exactly 1 policy, as a JSON object.
A policy contains a list of allowed and/or disallowed AAIDs, referring to specific authenticator implementations.
The policy for a certain operation can be specified in the context of the GetUafRequest object.
Example snippet (JavaScript) for a registration operation with pin_only policy:
const getUafRequest = {
op: "Reg",
context: JSON.stringify({username: userExtId, policy: "pin_only"})
}
Given a policy in the GetUafRequest context, nevisFIDO looks for a .json file with the same name.
There must be at least one file named default.json which serves as default policy.
This policy will be used when no policy is specified in the GetUafRequest context.
The following policies are included by default:
default: allows registration or authentication with all authenticators supported by Nevis.pin_only: allows only the PIN authenticators.biometrics_only: allows only biometric authenticators.password_only: allows only (alphanumeric) password authenticators.
Note that two authenticators supplied by the policy files are currently only supported by the Nevis Mobile Authentication SDK but not the Nevis Access App, these authenticators are:
- The Device Passcode authenticator
- The Password authenticator
Application Attestation (App Attestation)
For configuring Android and iOS app attestation, refer to the Application Attestation Concept Guide and the Policy configuration examples.
Metadata
The FIDO UAF specification describes metadata as follows:
It is assumed that FIDO Server has access to a list of all supported authenticators and their corresponding Metadata. Authenticator metadata contains information such as:
* Supported Registration and Authentication Schemes
* Authentication Factor, Installation type, supported content-types and other supplementary information, etc.
To make a decision about which authenticators are appropriate for a specific transaction, FIDO Server looks up the list of authenticator metadata by AAID and retrieves the required information from it.
nevisFIDO ignores any authenticators and prevents all operations, when there is no corresponding metadata entry.
The default metadata works for the NEVIS Access App.
You have to update the metadata if you are using either:
- a custom app based on the
NEVIS Mobile Authentication SDKor - a customized Whitelabel Access App
To support Full Basic Attestation for Android the metadata must contain the Google root certificates. These entries must be kept up-to-date.
Android Verification Level
Android Key Attestation relies on FIDO UAF Full Basic Attestation.
Whether Android Key Attestation is applied is controlled by the FIDO UAF policy.
Here you can choose between 2 verification levels for the FIDO UAF Full Basic Attestation:
default - does FIDO UAF Full Basic Attestation solely based on the FIDO UAF protocol specification.
In practice, this means it’s limited to verifying the certificate chain.
strict - conducts additional checks on the attestation extension of the TBSCertificate,
ensuring that all key material is kept in certified secure hardware and the phone bootloader was not manipulated.
The Nevis documentation provides additional information of how to create the necessary policy files:
Android Permissive Mode
Select disabled to fail the registration when the full basic attestation checks for Android fail.
Read the help of Full Basic Attestation - Android Verification Level for further information about these checks.
Select enabled to still perform the same checks, but not fail the registration even when checks fail.
Only a warning message will be logged.
Visit the Permissive Mode documentation for further information.
Android Reload Interval
Defines how often the Android attestation key revocation list is automatically refreshed.
Regular updates help protect the system against revoked or compromised keys.
The default interval is 6 hours, balancing key freshness with network usage.
Android Proxy Address
Configure a proxy for requests to the Android attestation key revocation service.
This is useful in environments where direct internet access is restricted or where security policies require proxy usage.
By default, no proxy is configured.
Android Proxy User
If your proxy requires authentication, you can enter the username here.
Android Proxy Password
If your proxy requires authentication, you can enter the password here.
Android Service Account
If required by the configured FIDO UAF policies, the integrity of the application will be validated.
On Android, nevisFIDO uses the Google Play Integrity API to perform this validation.
To enable this functionality, upload the service account JSON file provided by Google.
You can also use a variable containing either:
- a nevisAdmin secret file
- a Kubernetes file secret (
k8s-secret-file://).
iOS Team Identifier
The 10-character identifier of the team that signs your iOS applications, as listed on Apple's developer account portal.
This value is also known as the App ID prefix (without the trailing dot).
iOS DeviceCheck Key Identifier
The 10-character identifier of your DeviceCheck key.
This identifier is required to validate attestation receipts during iOS app attestation.
For more information, see Accessing Fraud Risk in Apple’s documentation.
iOS DeviceCheck Key
For app attestation on iOS, nevisFIDO uses Apple’s DeviceCheck service.
Specify the file that contains the DeviceCheck private key.
This key must be in PEM format.
For instructions on creating a DeviceCheck private key, refer to Apple’s official documentation.
You can also use a variable containing either:
- a nevisAdmin secret file
- a Kubernetes file secret (
k8s-secret-file://).
iOS Attestation Limit
The maximum number of app attestation keys that a device can generate within a 30-day period.
Typically, an application attestation key is generated once during the lifetime of the app — unless it expires or the app is reinstalled.
On compromised iOS devices, malicious clients may generate excessive attestation keys.
A high number of keys generated on a single device could be an indicator that the device has been compromised.
You should set this limit based on how frequently your application might reasonably be reinstalled within 30 days.
In development environments, frequent re-installations are common, so you may want to set a high number.
For more details, refer to Apple's documentation on assessing fraud risk.
Default value: 20
Proxy Address
This setting allows specification of a proxy URL through which requests to the Android & iOS backend services will be routed.
It is useful in environments where direct internet access is restricted or security policies mandate proxy usage.
By default, no proxy is configured.
Proxy User
This setting defines the username required for authentication with the configured proxy.
It should be provided if the proxy service requires authentication.
By default, this setting is unset.
Proxy Password
This setting sets the password used alongside the proxy username for authentication purposes.
It must be defined if the proxy server requires password-based authentication.
By default, this setting is unset.
Firebase Configuration
For sending push notifications, nevisFIDO needs to access Firebase, which is a push messaging service. For that, it requires an account and its corresponding credential.
Please visit the Firebase Console, create a project and download the service-account.json file. Please upload this file here.
Note that this file contains a private key, that gives access to your project's Firebase services. Keep it confidential at all times, and never store it in a public repository. Be aware that anybody who has access to this property, also has access to the file itself.
Firebase Proxy Address
The URL of the HTTP/HTTPS proxy used by nevisFIDO to access the Firebase Cloud Messaging service.
Note: The FCM dispatcher requires outbound access to the Google API service, specifically https://oauth2.googleapis.com for authentication and https://fcm.googleapis.com for accessing the FCM HTTP API.
In case proxies and/or company firewalls are in place the connectivity to these Google services must be ensured.
Firebase Proxy User
Username to authenticate for Firebase Proxy Address.
Firebase Proxy Password
Password to authenticate for Firebase Proxy Address.
Link Type
Choose between:
Deep Link: configures nevisFIDO to use a deep link (recommended).Custom URI: configures nevisFIDO to use a custom URI link.undefined: this pattern will not generate any link dispatcher configuration.
Deep links take more effort to set up, but they are the recommended option because they offer a better user experience.
Use Custom URI links only in mobile-only scenarios. A custom URI can only be opened on the device where the mobile app is installed, so it cannot be used to get from a browser on a desktop machine to a phone. The end-user is always expected to click the link on the same phone the Access App runs on.
Note: the selected type here and the corresponding URI/URL must be communicated when Ordering an Access App.
Further information about deep links and custom URI links can be found in the related settings.
Deep Link
Deep links or app links use the standard https:// scheme.
Enter a complete URL here.
We recommend adding a path component, as otherwise / will be used
and there often is no appropriate content on the root location.
Note that the link must point to a different host than the page that displays it.
A different subdomain is sufficient (e.g. login.example.com for the page and
links.example.com for the link); a separate domain is not required.
This is because iOS opens a universal link in the browser instead of the app
when it is tapped from a page on the same host.
You can use any web server or Nevis as the target.
When the user clicks the link, the OS of the mobile device
will first try to download an app link file from a /.well-known/ path on that domain.
You can configure Deep Link Host and Deep Link Resources to host these files.
The app link file is used by the OS to determine if a mobile app shall be opened, handing over the current URL.
If no mobile app can be determined, the deep link will be opened in the browser instead. Examples:
- user does not have the app installed
- no rule in the
/.well-known/apple-app-site-associationfile applies to the path
Because of these error cases, there should be content on the deep link URL.
We recommend creating a page that informs the user how to install the mobile app.
You can use the Hosting Service pattern to host this page on the Deep Link Host.
Deep Link Host
If you have uploaded any Deep Link Resources, then assign a Virtual Host.
The files will be hosted with a base path of /.well-known/.
The domain of the Deep Link must point to this Virtual Host.
If the user does not have the mobile app installed,
the Deep Link will be opened in the browser instead.
Deep Link Resources
Upload resources required for deep links.
Installation Page
You can upload the HTML page that your Deep Link points to.
This page is shown only when the mobile app is not installed and should provide installation instructions.
You can also upload static resources (e.g. CSS and images) used by this page.
Uploaded files will be hosted at the root location (/) of the Deep Link Host.
If you want to host them on a sub-path, use the Hosting Service pattern instead.
App Link Files
App link files are JSON files which provide information about the mobile app. Apple and Google use different terms, and expect different filenames and contents.
Visit our official documentation for more information.
iOS
The file must be named apple-app-site-association without any extension and will be hosted at /.well-known/apple-app-site-association.
The file must be created manually and match the following structure:
{
"applinks": {
"details": [
{
"appIDs": [
"<team id>.<bundle id>"
],
"components": [
{
"/": "open",
"?": {
"dispatchTokenResponse": "*"
},
"caseSensitive": false
}
]
}
]
}
}
appIDs: refer to the app. Each entry consists of two components as follows: <TeamID>.<bundleID>,
for details or about how to obtain it, see Apple documentation about app links.
components: restrict which URLs open the app. The / entry must match the path used in the
Deep Link, and the ? entry must allow the dispatchTokenResponse query parameter.
When the mobile app is installed or updated, iOS fetches this file from the server and stores it for later, to verify the paths in deep links the user clicks on.
For more information, visit app links.
Android
The file must be named assetlinks.json with the extension and will be hosted at /.well-known/assetlinks.json.
The file can be generated with the Statement List Generator using the following information:
- Hosting site domain: enter the domain used in the
Deep Link. It should point to the assignedDeep Link Host. - App package name: enter the package name of your app. If you are using a NEVIS branded Access App, that would be
ch.nevis.security.accessapp. - App package fingerprint (SHA256): enter the fingerprint of the certificate your app has been signed with.
For more information, visit Android App Links.
Note that certain Chinese browsers do not support Android App Links: 360, QQ, UC.
The file must be created manually and match the following structure:
[
{
"relation": [
"delegate_permission/common.handle_all_urls"
],
"target": {
"namespace": "android_app",
"package_name": "<package name>",
"sha256_cert_fingerprints": [
"<certificate fingerprint>"
]
}
}
]
Custom URI Link
Custom URI links will open the mobile app directly, they do not use the standard https:// scheme.
The scheme must be registered for the mobile app.
See Link Structure for Custom URIs for details.
Example:
myaccessapp://x-callback-url/authenticate
nevisIDM
For user and credential management, nevisFIDO needs nevisIDM.
Assign a nevisIDM Instance or nevisIDM Connector here.
This connection uses Client TLS and the trust is not built up automatically.
Client ID
Enter the extId of the nevisIDM Client.
Only 1 client is supported.
Key Store
The key nevisFIDO uses to connect to nevisIDM Instance.
Important to note that the certificate that belongs to this key must exist in nevisIDM as the certificate credential of the nevisfido technical user.
Trust Store
The trust store nevisFIDO uses to connect to nevisIDM Instance.
Registration Token Timeout
Defines the maximum time a client has to redeem a registration token after the generation of the token by nevisFIDO.
Once the token is redeemed, the Registration Response Timeout applies: the client has a maximum time to send a RegistrationResponse to nevisFIDO.
The default value is 5 minutes. If no time unit is provided, seconds will be used.
This timeout is relevant in the Out-of-Band Registration use-case.
Authentication Token Timeout
Defines the maximum time a client has to redeem an authentication token after the generation of the token by nevisFIDO.
Once the token is redeemed, the Authentication Response Timeout applies: the client has a maximum time to send an AuthenticationResponse to nevisFIDO.
This timeout is relevant in Out-of-Band Authentication.
Registration Response Timeout
Defines the maximum time duration between the generation of the RegistrationRequest by nevisFIDO and the RegistrationResponse by the FIDO UAF client.
If the client has not sent the response after this time, a client timeout occurs.
The default value is 5 minutes. If no time unit is provided, seconds will be used.
This timeout is relevant in registration use-cases, such as:
Authentication Response Timeout
Defines the maximum time duration between the generation of the AuthenticationRequest by nevisFIDO and the AuthenticationResponse by the FIDO UAF client.
If the client has not sent the response after this time, a client timeout occurs.
The default value is 2 minutes. If no time unit is provided, seconds will be used.
This timeout is relevant in the authentication use-cases, such as:
Device Service Timeout
Defines the maximum time difference that is accepted between the time in the creationTime attribute
in device service requests and the time when the server processes the request.
This value is close to the time drift that is accepted between the mobile device clock and the server clock.
If the time drift is bigger than this value, the operation will fail. This is indicated by a JWS in request is expired error in the logs.
This configuration value influences the behavior of the following HTTP API endpoints:
The default value is 5 minutes. If no time unit is provided, seconds will be used.
Push Message Timeout
The duration how long a push message is valid.
Should match the Authentication Token Timeout.
If no unit is given seconds is assumed.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
FIDO UAF Credential Policy
The extId of the nevisIDM credential policy to be used for FIDO UAF credentials.
This setting allows you to specify the extId of the policy to be used for the credential type.
Use it in case your project is using custom policies, and you need fine-granular control over the policy assigned to the credential.
Modify operations do not update existing credentials.
Dispatch Target Policy
The extId of the nevisIDM credential policy to be used for Dispatch Target Generic credentials.
This setting allows you to specify the extId of the policy to be used for the credential type.
Use it in case your project is using custom policies, and you need fine-granular control over the policy assigned to the credential.
Modify operations do not update existing credentials.
iOS App Attestation Policy
The extId of the nevisIDM credential policy to be used for iOS App Attestation Generic credentials.
This setting allows you to specify the extId of the policy to be used for the credential type.
Use it in case your project is using custom policies, and you need fine-granular control over the policy assigned to the credential.
Modify operations do not update existing credentials.
User Name
Configure what is expected as username in incoming API calls.
Choose between extId and loginId.
Deregistration Authorization
Configure if a SecToken is required to perform deregistration.
Cancel Endpoint
Enable or disable the POST /nevisfido/cancel endpoint, which allows cancelling ongoing mobile authentication operations.
Only enable this if the endpoint is secured, for example via a nevisProxy Virtual Host with an Authentication Realm.
Custom Dependencies
Add plugins to nevisFIDO.
The easiest way is to upload a JAR file with Java code. This is the only option for classic VM deployments.
In Kubernetes deployments, you can use a Kubernetes secret instead. This way you can avoid it that the JAR is pushed to the deployment GIT.
Proceed as follows:
- Create 1 Kubernetes secret containing the JAR file(s) in the target namespace.
- Click the
varbutton to use a variable here and enter a name for the variable. - Add the variable to your inventory and reference files from the Kubernetes secret there.
Additional configuration may be required to use the plugin.
Use the Generic nevisFIDO UAF Instance Settings pattern to add the required entries
to the nevisfido.yml.
Additional Settings
Assign add-on patterns to customize the configuration of nevisFIDO.
nevisIDM Database
Plugin: nevisadmin-plugin-nevisidm
Configures the nevisIDM database. Assign to a nevisIDM Instance as Database.
Do not assign the same pattern to multiple instances!
When deploying to Kubernetes, the database schema and connection user are set up automatically.
The database schema will be automatically migrated when upgrading to a newer version of Nevis on the next deployment.
This feature can be disabled with the Database Management drop-down.
In classic VM deployments, there is no schema creation and migration. You have to do Database Preparing.
If you want to use an Oracle database, additional configuration is required as we cannot bundle any Oracle dependencies due to licensing restrictions.
In Kubernetes deployments you can provide these dependencies with a Volume Claim.
In classic deployment you have to upload a JDBC Driver in this pattern.
Database Type
Choose between MariaDB, Oracle and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
JDBC Driver
Due to licensing restrictions, we cannot ship any Oracle dependencies. If you want to use an Oracle database, upload a JDBC driver here.
The driver can be downloaded from Oracle.
Note that both the component (nevisidm) and the database migration tool (nevisidmdb) need a JDBC driver to access the database.
In a classic deployment, the driver will therefore be added to 2 different instance directories.
In Kubernetes setups, and when Database Management is enabled, you have to configure Volume Claim instead of uploading the JDBC driver here.
This is to avoid committing binary files to Git during the deployment process.
Volume Claim
Due to licensing restrictions, we cannot ship any Oracle dependencies.
If you are using an Oracle database, are deploying to Kubernetes, and Database Management is enabled (complete or schema),
then you have to provide a Kubernetes volume containing an Oracle driver and client.
For more information, see Preparing Oracle Volume.
Enter the name of that volume here.
The volume will be mounted in the nevisidm-dbschema image to set up and patch the database schema.
The volume will be mounted in the nevisidm image to connect to the database.
Because of that, there is no need to upload a JDBC Driver.
Index Tablespace
Name of the index tablespace for the oracle database. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Data Tablespace
Name of the data tablespace for the oracle database. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Application Role
Name of the application role for the oracle database. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Owner Role
Name of the owner role for the oracle database. It's recommended to keep the default value unless the pattern is used with an existing database that has a different one.
Min Pool Size
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime
This setting controls the maximum lifetime of a connection in the pool.
After the specified lifetime, database connections are removed from the pool, closed, and reopened.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Connection Parameters
Enter parameters for the DB connection string.
Enter 1 parameter per line.
Lines will be joined with &.
When connecting to a MariaDB database some query parameters will be added when not present. The following parameters will be enforced then:
pinGlobalTxToPhysicalConnection=1
useMysqlMetadata=true
cachePrepStmts=true
prepStmtCacheSize=1000
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisIDM Instance
Plugin: nevisadmin-plugin-nevisidm
The pattern represents a nevisIDM instance. The instance is named according to the pattern.
Multi-instance setups
In case of deploying the instance to multiple target hosts, the file auditing and asynchronous processing is enabled on the first instance only.
This is to prevent multiple instances from processing the same event concurrently, which may occasionally lead to errors, such as sending out the same e-mail twice, or splitting the audit log file over several instances.
Hint for pattern renaming
When the 'Instance Name' property is not filled, the pattern uses the pattern name as instance directory at the target host.
To rename the pattern, do the following:
- Rename the pattern in the GUI.
- Rename the instance directory and associated systemd files on the deployment hosts.
- Deploy
In case step 2 is omitted the old instance is shut down during deployment.
These steps are documented in the nevisAdmin 4 technical documentation: User Guide / Configuration Projects / Working with Patterns.
Port
Port the nevisIDM instance is listening on.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Encryption Key
Enter an encryption key as Base64. This is mandatory because of security.
For existing setups please enter the value of security.properties.key
from your /var/opt/nevisidm/<instance>/conf/nevisidm-prod.properties file.
If you do not know which value was used so far, you may generate a new key
and set Encryption Fallback to enabled to ease migration.
When there are no URL tickets or encrypted properties the fallback can be disabled.
For new setups the key should consist of random bytes. The following openssl command generates a random key and returns the Base64 value:
openssl rand -base64 16
Note that when Encryption Algorithm is set to AES, the key length must be 8, 16 or 24 bytes. 8 byte long AES keys
are strongly discouraged for new instances, but supported for legacy instances.
Encryption Fallback
Initialization vector ("iv") fallback mechanism
This must be set to true for customers who previously had no value set for
security.properties.key / propertiesKey (old name) in the properties file
and had encrypted values already stored in the database. Otherwise, the old
values encrypted by default value will not be readable. If the database does not
contain encrypted properties or unused URL tickets, it is safe to leave this
turned off, and it is adviced to be turned off for stronger security.
SecToken Trust Store
Assign a Trust Store provider pattern to use for setting up trust between nevisIDM and nevisAuth. If no pattern is assigned the signer key will be provided by the nevisAdmin 4 PKI.
Status Port
This port is used in Kubernetes deployment to check if the instance is up after deployment.
Messaging Port
Port of the messaging service.
Enter a different port to deploy multiple nevisIDM instances on the same target host in classic VM deployment.
Database
Assign a nevisIDM Database.
Query Service
Enable the Query Service to allow full-text searches on the Admin GUI and REST API. Please note that using the Query Service requires the nevisIDM REST API to be exposed with the nevisIDM REST Service pattern.
Log Settings
Add logging configuration for nevisIDM.
Multi Client Mode
If IDM should support multiple Clients.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected. Generatesserver.tls.require-client-auth=true.disabled: Clients must not present a client certificate. The server will not request a certificate. Generatesserver.tls.require-client-auth=false.
The
Frontend Trust Storeis only used whenrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
SMTP Server
Host:port of the SMTP server used for sending emails.
Configure if you prefer to provide the SMTP server with a single configuration,
instead of configuring both SMTP Host and SMTP Port.
SMTP Host
The name of the host on which the SMTP server is running.
SMTP Port
Port of the SMTP server.
SMTP TLS Mode
Choose between:
disabled- TLS is disabled. TheSMTP Trust Storeis not used.STARTTLS- uses theSTARTTLScommand (see RFC 2487) to switch to TLS if supported by the SMTP server.
Trust Store
Assign a Trust Store provider pattern to use for setting up trust between nevisIDM and the SMTP server.
SMTP User
Set if a user is required to connect to the SMTP server.
SMTP Password
Set if a password is required to connect to the SMTP server.
Mail Sender
The default sender address for e-mails.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Encryption Algorithm
Encryption algorithm.
Encryption Cipher
Encryption cipher.
Default: AES/CBC/PKCS5Padding for historical reasons.
AES/GCM/NoPadding advised for new installations.
Migration of old cipher is possible with EncryptionFallbackJob.
Bind Host
Enter a custom host name to listen on.
Status Host
Enter a custom host name to open the Status Port on.
If not set 0.0.0.0 will be used in case of Kubernetes deployment
and localhost for deployment to VMs.
Default Language
Sets default language for nevisIDM.
It is the same as using web.gui.languages.default in properties.
If given by both way, the value in properties will be used.
See nevisIDM Reference Guide (chapter Configuration files) for details.
Batch Job Store
Select db to track job execution in the database.
This ensures that a given batch job can only run once at the same time.
Use this configuration when you have multiple lines / replicas.
Select ram to store track job execution in memory.
You may use this value when you have only 1 line / replica.
Custom Resources
Files uploaded here will be added to the conf folder of the nevisIDM Instance.
Additional Settings
Assign add-on patterns to customize the configuration of nevisIDM.
nevisLogrend Instance
Plugin: nevisadmin-plugin-nevisauth
Configures a nevisLogrend Instance.
Port
Enter the port the nevisLogrend shall listen on.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Log Settings
Add logging configuration for nevisLogrend.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Bind Host
The host name that this nevisLogrend instance will bind to. nevisProxy will connect to the same host name.
Base Path
Set a custom path for nevisLogrend resources (e.g. CSS). The path will be made accessible in nevisProxy.
You must change the path when using multiple nevisLogrend instances on the same virtual host.
Configuration: logrend.properties
Add or overwrite properties in logrend.properties.
You can use the following expressions (format: ${...}):
${protocol}- depends onHTTPssetting${host}- depends onBind Hostsetting${port}- will be replaced withTCP Service Port${instance}- contains the instance name
This is an advanced setting which should be used in complex setups only. If you have to configure anything here we are looking forward for your use case.
Custom MIME Types
Add or overwrite MIME types.
nevisLogrend supports common MIME types by default.
MIME types which are not known to the component, have to be defined in the mimetypes.properties file.
You can add or overwrite entries in the mimetypes.properties here.
The default content is:
ico=image/x-icon
json=application/json
woff=font/woff
woff2=font/woff2
Custom Properties (LoginRendererServlet)
Advanced configuration to add, overwrite, or remove init-param elements of the LoginRendererServlet servlet.
To remove enter just the name with an empty value.
By default, the servlet has the following init-param elements:
-
PropagateRemoteHeaders:- value:
Set-Cookie - reason: to ensure nevisLogrend can issue
LANGcookie.
- value:
-
authmethod.Unlock:- value:
embedded - reason: the nevisProxy default for the
unlockmethod is to open a popup. This is not appropriate nowadays.
- value:
-
RenderingProvider:- value:
remote:NevisLogrendConnector_<name>:/nevislogrend/index.vm?logrendresourcepath=/nevislogrend - required for the connection to nevisLogrend. Do not change this unless you know what you are doing.
- value:
Additional Settings
Assign an add-on pattern to customize the configuration of nevisLogrend.
nevisMeta Database
Plugin: nevisadmin-plugin-nevismeta
Configures nevisMeta to use a MariaDB database for storing sessions.
Assign to nevisMeta Instance as Database.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployment you have to provide an empty database and a schema user. The schema user is used by nevisMeta to populate the database during startup.
Setup instructions can be found in the nevisMeta technical documentation.
Database Type
Choose between MariaDB and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Note: Support for PostgreSQL is experimental.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Schema User
The user which will be used to connect to the database and create the schema (tables).
The database must have been created already (CREATE DATABASE)
and the user must have CREATE privileges for this database.
Example: umet01
Schema User Password
The password of the user on behalf of the schema will be created in the database.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
Key Store
Define the key store to use for 2-way HTTPs connections for DB endpoint.
This configuration only accept PEM Key Store pattern configuration.
Noted: This is an experimental configuration
Min Pool Size
Set the minimum connection pool size.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Max Lifetime
This setting controls the maximum lifetime of a connection in the pool.
After the specified lifetime, database connections are removed from the pool, closed, and reopened.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Connection Parameters
Enter parameters for the DB connection string.
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Enter 1 parameter per line.
Lines will be joined with &.
Examples (from various Nevis components):
pinGlobalTxToPhysicalConnection=1
useMysqlMetadata=true
autocommit=0
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL
nevisMeta Instance
Plugin: nevisadmin-plugin-nevismeta
Represents a nevisMeta instance. The instance is named according to the pattern.
Hint for pattern renaming
When the 'Instance Name' property is not filled, this pattern uses the pattern's name as instance directory at the target host.
To rename this pattern, follow these steps:
- Rename the pattern in the GUI.
- Rename the instance directory and associated systemd files on the deployment hosts.
- Deploy.
In case step 2 is omitted, the old instance is shut down during deployment.
For more information, see User Guide / Configuration Projects / Working with Patterns.
Port
Port the nevisMeta instance is listening on.
Status Port
This port is used to check if the instance is up after deployment.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Log Settings
Configure the nevisMeta log files.
Database
Assign a nevisMeta Database.
Frontend Key Store
This setting specifies the key store used for the HTTPS endpoint.
The certificate in the key store must be valid for all frontend addresses.
In Kubernetes deployments, the certificate subject must contain a CN entry with the service name.
If no pattern is assigned, automatic key management will provide a key store.
Frontend Trust Store
Configure a trust store for validating incomining connections with a client certificate.
This setting is relevant only when Client Authentication is set to required or requested.
If no pattern is assigned here, automatic key management will be used to provide the trust store. Note that automatic key management works only for callers that use an automatic key store and are part of the same nevisAdmin project.
Client Authentication
Setting for mutual TLS (mTLS) on the HTTPS endpoint.
Choose between:
required: Clients must present a valid client certificate. Connections without a certificate, or with an invalid certificate, will be rejected.requested: Clients may present a client certificate. If a certificate is provided, it must be valid. If no certificate is provided, the connection will still be accepted.disabled: Clients must not present a client certificate. The server will not request a certificate. Presenting one may cause the connection to fail.
The
Frontend Trust Storeis only used whenrequestedorrequiredis selected. It must contain the issuing CA certificate(s) for client certificates.
TLS Protocol(s)
The TLS protocol versions supported for inbound connections to this endpoint.
SecToken Signer Trust Store
Assign a Trust Store which is used to validate the signature of a received NEVIS SecToken.
There are 2 use cases which require validation:
- when a user accesses the
nevisMeta Web Consolethe SecToken is signed usingNevis SecToken/Key Store. - when nevisAuth calls nevisMeta the SecToken is signed using
nevisAuth Instance/Internal SecToken Signer.
If no pattern is assigned the trust store will be provided by nevisAdmin 4 automatic key management.
However, this requires that automatic key management is used in the Nevis SecToken and nevisAuth Instance patterns.
Startup Probe Delay
Delay for before Kubernetes will call the startup probe.
Set a higher value if deployment fails due to slow startup of the pods.
Memory Limit
This setting defines the maximum amount of RAM than can be used by this instance.
VM Deployment
By default, the Java process will use 1/4 of the available RAM.
Depending on how many instances are deployed to the same target host this may be either too much or too little.
The value configured here will be used for
the maximum heap size of the Java process (-Xmx).
Kubernetes Deployment
In Kubernetes deployment the value configured here will be ignored and the Java process will be configured to use a percentage of the available RAM.
Note that -Xmx is not set to avoid file changes when adapting the limit.
As the docker container runs only 1 process the JVM flags
-XX:+UseContainerSupport and -XX:MaxRAMPercentage=80.0 will be applied
so that Java process can use up to 80% of the configured limit.
Initial Memory Ratio
Use the given percentage of Memory Limit for the initial memory usage (-Xms).
This setting applies to classic VM deployments only.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Open Telemetry
OpenTelemetry is used for several use cases:
- cross-component tracing in logs
- exposing metrics
By default, OpenTelemetry is enabled and a Java agent is loaded.
If that Java agent is not present on the machines you are deploying to,
then you have to provide it at /opt/agent/opentelemetry-javaagent.jar or select disabled.
Additional Settings
Assign add-on patterns to customize the behavior of this nevisMeta instance.
Custom Properties
Configure properties of the nevisMeta.
Add or overwrite properties by entering a value.
Remove properties generated by this pattern by leaving the value empty.
Examples:
| Key | Value |
|---|---|
| database.migration.automatic | false |
nevisProxy Instance
Plugin: nevisadmin-plugin-nevisproxy
The pattern represents a nevisProxy instance.
Create at least one Virtual Host pattern and assign this pattern.
Hint for pattern renaming
When the 'Instance Name' property is not filled, this pattern uses the pattern's name as instance directory at the target host.
To rename this pattern, do the following:
- Rename the pattern in the GUI.
- Rename the instance directory and associated systemd files on the deployment hosts.
- Deploy.
In case step 2 is omitted, the old instance is shut down during deployment.
For more information, see User Guide / Configuration Projects / Working with Patterns.
Instance Name
Enter the instance name.
If not set, the pattern name will be used as the instance name.
When deploying to Kubernetes, this setting will be ignored and the instance name will be default.
Log Settings
Add logging configuration for nevisProxy.
Apache SSL Cache
Configures the Apache storage type of the global/inter-process SSL Session Cache.
Uses the default high-performance cyclic buffer inside a shared memory segment in RAM.
This is the recommended and default SSL Cache for nevisProxy, which is required to enable SSL session resumption.
For more information, see the official Apache documentation about the SLLSessionCache directive.
SSL Cache Size
Configures the approximate size of the Apache SSL Cache.
The minimum allowed value is 1 KB. The maximum is 100 MB.
If not, the default from Apache is used.
SSL Cache Timeout
Configures the number of seconds before an SSL session expires in the SSL Session Cache.
For more information, see the documentation of the SSLSessionCacheTimeout directive.
Instance Rename Detection
During deployment nevisAdmin 4 checks if the instance has been renamed by checking the last metadata file deployed on the target host given the pattern ID.
If instance rename is detected the current instance is stopped.
This check should be disabled if multiple environments are simulated on the same server.
This setting is relevant for classic VM deployment only.
Start Inactive
In a classic VM deployment the instance is restarted when a configuration file changes that requires a restart. The instance is not restarted when a configuration file changes that does not require a restart.
This setting defines if the instance should also be started when it is down.
This setting applies to classic VM deployment only. In Kubernetes deployment the container pods are always recreated when any configuration file changes.
Startup Probe Delay
Time to wait before checking Kubernetes readiness on startup.
You may have to increase this value if start of the nevisProxy service fails because of a failing readiness check.
Sets initialDelaySeconds of the Kubernetes startup probe.
Check Minimum Version
Select enabled to perform basic version checks.
In classic VM deployment we run a command on each target host, to check which version of the component is installed.
In Kubernetes deployment we check the version of the docker image instead.
This check can be disabled for testing purposes.
Restart Policy
Determines the instance behavior when a configuration change triggers an optional restart.
Select one of:
-
eager- the instance will restart when deploying the new configuration; -
lazy- the instance will skip optional restarts.
Restart Condition
Enter an expression to prevent nevisProxy from being restarted even if the configuration changes.
nevisProxy will only be restarted if the exit status is 0.
The expression must always terminate.
In Kubernetes deployment this setting is ignored.
A use case where this is required is when nevisProxy is deployed to multiple hosts and listens on a shared IP which is bound on 1 host only.
ip address show dev eth1 | grep -q "172.29.0.5"
Example for multiple shared IPs:
ip address show dev eth1 | egrep -q "172.29.0.5|172.29.0.6"
Recommendations:
- Run the command manually on the target host to be sure that it works for you.
- You can check the exit status of the last command by running
echo $?
Password Getter
Choose between:
recommended: usesnevisadminfor Kubernetes and classic deployments.
The recommended value may change in future releases.
-
nevisadmin: uses a script deployed by nevisAdmin. Does not work for PKCS11. -
nevisproxy: uses/opt/nevisproxy/bin/keystorepwgetto lookup passwords for encrypted key material.
Requires nevisProxy version 4.4 or later.
Does not support lookup of the password for the key.pem of PEM Key Store.
neviskeybox: uses/opt/neviskeybox/bin/keystorepwgetto lookup passwords for encrypted key material.
nevisKeybox must be installed on the target system. Does not work in Kubernetes deployments.
Crash Recovery Strategy
Defines how to handle process crashes.
Choose between:
recommended: usesrecoverfor classic andkillfor Kubernetes deployments;recover: the child process is recovered by the parent process;block: every request will be blocked by503 Service Unavailablestatus code;kill: the whole nevisproxy process (including the parent process) is killed.
This works only if the owner of the child process has the permissions to kill the parent process (for example in some Kubernetes setups).
Otherwise, this option works like block.
Note for block and kill: these actions take place if at least one request was being processed when the crash occurred.
These features can be useful for liveness test in Kubernetes setups, so the given pod can be terminated normally in case of a crash.
Using one of these options in a classic setup requires to restart nevisProxy with an external tool after a crash.
SSL VHost SNI Policy
Set compatibility policy for SNI client access to virtual hosts
Possible values are:
strictsecureauthonlyinsecure
The following defaults are used:
- classic VM deployment:
secure - kubernetes setup:
authonly
Considerations when deploying to Kubernetes:
- if the Ingress is SNI aware, you should set this value at least to
secureto avoid vulnerability to CVE-2025-23048. - if the Ingress is not SNI aware, make sure that the entrypoint is protected against CVE-2025-23048.
You can find more technical information here: https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslvhostsnipolicy
Default Virtual Host
The default virtual host of this nevisProxy instance.
The default will be used for requests without a Host header
or if there is no host with a corresponding frontend address.
Additional Settings
Assign add-on patterns to customize the behavior of this nevisProxy instance.
nevisProxy Remote / Hybrid Session Store
Plugin: nevisadmin-plugin-nevisproxy
Configures nevisProxy to use a remote database for storing sessions.
Assign to Virtual Host as Session Store.
Use this pattern when in-memory session storage cannot be used. Note that in-memory sessions may be sufficient in the following cases:
- classic (VM) deployment: only 1 line or load balancing towards proxy is session sticky
- Kubernetes deployment: only 1 pod (not recommended)
The session store is used only when there are filters or servlet which require a session.
In particular, this is the case when you assign an Authentication Realm to applications.
You can choose between remote, or hybrid session store. An overview about different types can be found here. The hybrid session store can be used in classic deployment only.
When deploying to Kubernetes, the database and connection user will be created automatically. The database schema will be migrated automatically when upgrading Nevis on the next deployment.
In classic VM deployment you have to create the database including tables.
Setup instructions can be found in the nevisProxy Technical Documentation.
For details see Configuration of MariaDB-based remote session store
or Configuration of Postgres remote session store.
Database Type
Choose between MariaDB and PostgreSQL.
We recommend using MariaDB as it is supported by all Nevis components that have a database.
Database Host
Enter the host name of the database service.
The database service must be up when you deploy.
In a classic deployment the Database User and Database Password is used to connect.
In Kubernetes deployment a connection user and password will be generated
and the Root Credential will be used to set up the database schema.
Database Name
Here you can change the name of the database.
The database name only needs to be changed when the database service contains multiple databases.
In Nevis ID, leaving this setting empty uses the component-specific default
database name with the inventory namespace suffix. The defaults are
nevisfidouaf_<namespace> for UAF, nevisfido2_<namespace> for FIDO2, and
nevisproxy_<namespace> for nevisProxy. Existing database contents are not
migrated when a default changes. To keep using an existing database, explicitly
configure nevisfido_<namespace> for UAF or FIDO2, or
replicated_session_store_<namespace> for nevisProxy. Namespace suffixes are
case-insensitive.
Root Credential
Enter the name of a Kubernetes Secret containing the credentials for the database management job.
This setting is required in Kubernetes deployments when Advanced Settings > Database Management is
set to complete or schema.
It is not required when Database Management is set to disabled.
With complete, the Secret must contain the database management user:
username: <root-user>
password: <root-password>
With schema, the database management user can be omitted. The database and users must already
exist, and the Secret must contain the schema-owner and application users:
ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>
With complete, the application and schema-owner users are created with the credentials specified in
the Secret.
Because schemas are used, create a separate Kubernetes Secret for each database pattern with the application and schema-owner credentials when using Oracle or PostgreSQL. Store passwords in Secrets or an external secret provider, not directly in pattern values.
Root Credential Namespace
Set if the Root Credential is in a different Kubernetes namespace.
Database User
Database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
Database Password
Password for the database connection user.
This setting is used in the following cases:
- Classic deployments (VM)
- In Kubernetes when 'Database Management' (Advanced Settings) is set to 'disabled'.
TLS Encryption
Configure how TLS is used when connecting to the database:
disabled– Connect without TLS (no encryption).trust– Use TLS, but skip certificate and hostname validation.verify-ca– Use TLS with certificate validation, but without hostname verification.verify-full– Use TLS with full validation: encryption, certificate verification, and hostname verification.
When certificate validation is enabled and the server certificate is not trusted by the component, you must configure
the Trust Store setting.
As the default trust varies by component (some use the Java default trust store, others also include OS-level trust stores),
configuring Trust Store is recommended whenever you use private CAs or self-signed certificates.
Trust Store
Assign a trust store which provides the CA certificate of the DB endpoint.
Key Store
Define the key store to use for 2-way HTTPs connections for DB endpoint.
This configuration only accept PEM Key Store pattern configuration.
Noted: This is an experimental configuration
Session Store Peer Address
The hybrid session store requires that the nevisProxy Instance is deployed on 2 lines.
For illustration purposes let's call the hosts where the instances are deployed p1 and p2.
Enter the URL where the other nevisProxy Virtual Host exposes its local session store.
The URL must be reachable and should not go via a load-balancer to ensure that the request reaches the peer proxy directly.
You can use variables to ensure that the correct host name is used for the configuration on each line. For instance, the variable may be a host variable and have the following values:
- for server
p1use:https://p2:443 - for server
p2use:https://p1:443
Alternatively, you can use a semantic host name and and define this name in /etc/hosts on both p1 and p2.
Example: https://proxy-peer:443
Session Store Path
Enter the path where the local session store shall be exposed and accessed by the nevisProxy peer.
Peer Servlet Strategy
Controls the used strategy of the Peer Servlet:
FAILOVER: The loadbalancer sends all requests to the same instance (instance A). If instance A goes down, the loadbalancer will send now all requests to instance B. The loadbalancer should only switch back to instance A if it has been restarted.DISTRIBUTED: The loadbalancer assure at least 90% session stickiness to both instances, for example by using the client IP address. Once the request for a session goes to the other instance, this one will get the session information from the first instance and copy into its local session store.
Session Store Access Restriction
This optional configuration is available when Mode is set to hybrid.
Assign an Access Restriction pattern to define the source IPs that are allowed to access the Session Store Path.
Min Pool Size (MariaDB)
Set the minimum connection pool size.
This configuration is ignored for PostgreSQL databases, as it is not supported by the PostgreSQL JDBC driver.
The connection pool will always attempt to maintain at least the minimum pool size.
However, the number of open connections may temporarily fall below the minimum in the following cases:
- During pool initialization.
- When connections are terminated due to idle timeout, maximum lifetime, network issues, or database server configuration.
Max Pool Size
Set the maximum number of available and borrowed (in use) connections that a pool maintains.
If the maximum number of connections is borrowed, no connections will be available until a connection is returned to the pool.
This setting allows the number of connections in the pool to increase as demand increases.
Max Idle Time
Sets the maximum amount of time that unused excess connections stay in the pool before it is considered stale and is removed (closed) to free up resources.
Database Management
The pattern controls whether the database and its schema are managed during installation and upgrades. For a complete installation and lifecycle guide, see Database management approaches.
The complete option performs the initial database preparation, such as creating the database or
Oracle tablespaces, creates the required database users, and runs schema migrations.
The schema option skips the initial preparation and runs schema migrations only. The database,
schema-owner user, and application user must already exist. Provide the schema-owner and application
user credentials in the root credential Secret. The root user information can be omitted with this
option. This is often a good balance when a DBA or customer provisioning service owns database
creation and role management, but automatic schema migrations are still desired. Select disabled
when migrations require explicit DBA approval and execution.
Select disabled to opt out of database management. In this case, create and migrate the database
schema yourself. Run the component dbschema image as a separate Kubernetes Job before the initial
deployment and before upgrades that change the schema. The migration job must be configured with
NEVIS_DBSCHEMA_BOOTSTRAP=false when role management is performed externally.
This feature is set to recommended by default. In Kubernetes deployments, recommended uses
complete. In classic VM deployments, it uses schema if the pattern supports Schema User and
Schema Password; otherwise, it uses disabled.
Session Store Mode
Select one of:
-
classic- sessions are stored in the remote database only. Recommended setting for production setups. -
hybrid- adds a local cache to improve the performance of the session store. This mode requires a session-sticky load balancer in front of nevisProxy. The generated configuration may change in future versions.
Database Schema Check
Select one of:
-
enabled- the database schema and integrity constraints are checked on startup to ensure they match the requirements of theRemote Session Store. -
disabled- the database schema and integrity constraints are not checked on startup.
Note: On certain MariaDB versions, the check produces fake errors due to a MariaDB bug.
By setting this parameter to disabled, you can skip the check.
Custom Parameters
Add custom init-param for the configured Database Type.
Check the nevisProxy technical documentation for supported parameters
either of the servlet class ch::nevis::nevisproxy::servlet::cache::mysql::MySQLSessionStoreServlet for the MariaDB Database Type or of the servlet class ch::nevis::nevisproxy::servlet::cache::postgresql::PostgreSQLSessionStoreServlet for the PostgreSQL Database Type
Connection Parameters
Enter parameters for the DB connection string.
Enter 1 parameter per line.
Lines will be joined with &.
The default for MariaDB:
ping_timeout=2
connect_timeout=10
and for PostgreSQl:
connect_timeout=10
The default value will be used only when no parameters are entered.
If you want to keep the default parameters, add them as well.
Connection URL
Set only if you have to use a JDBC connection string which the pattern cannot generate.
If the prefix of the connection string works for you
and you only have to add or overwrite query parameters, set Connection Parameters instead.
If you have to use this setting, please consult your setup with your integration partner.
In Kubernetes deployments the connection string configured here is used by the component only. It is not used to set up and migrate the database schema.
Thus, this setting should only be used in classic deployments,
or when Database Management is disabled.
Instead of using 'jdbc:mysql' either
- Use the high-level configuration for the Database Host instead of providing a custom URL
- Add the query parameter permitMysqlScheme to the custom URL