Skip to main content

nevisadmin-plugin-nevisidm

Azure Service Bus

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

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 nevisIDM Instance Settings

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.

OATH Authentication

Ask the user for a One-Time Password (OTP) from an authenticator app.

Use in combination with an app hat supports OATH TOTP, such as the Google or Microsoft Authenticator.

The nevisIDM Password Login or nevisIDM User Lookup step has to be executed before this step to set the user in the session.

This step can be used as a follow-up of nevisIDM Second-Factor Selection.

The user has to have a OATH credential with label Default. To create this credential, use the OATH Onboarding pattern.

nevisIDM

Reference the nevisIDM Instance which has been used for first factor authentication.

Authentication Level

Authentication level that is set on success.

On Success

Configure the step to execute after successful authentication.

If no step is configured here the process ends and the user will be authenticated.

Login Type

Sets the type of login identifier which will be used to look up the user.

In nevisIDM any client whose users should be able to log in with their email address must have the following entry in the Client policy: authentication.loginWithEmail.enabled=true

OATH Onboarding

Onboard an authenticator app that supports OATH TOTP, such as the Google or Microsoft Authenticator.

The user has to scan a QR code to complete the onboarding.

This pattern is experimental and the rendered GUI may be changed in future releases, depending on customer requirements.

The user must have been set in the session already. For instance, put a nevisIDM Password Login or nevisIDM User Lookup step in front of this step.

You may can also assign this step as Not Found to nevisIDM Second-Factor Selection.

nevisIDM

Reference the nevisIDM Instance which has been used for first factor authentication.

On Success

Assign a step to execute after onboarding the authenticator app.

We recommended to assign OATH Authentication to validate that the onboarding was successful.

Also note that the nevisIDM Second-Factor Selection pattern only considers OATH credentials which have passed the OATH Authentication once.

If no step is assigned the process ends and the user will be authenticated.

nevisIDM Account Recovery

Account recovery provides the user an alternative way to log in.

This can be useful in cases when the user lost access to their account, for example, by losing the phone that is registered as second factor.

For background information about the credential and database tables used by this feature, see:

nevisIDM

Reference a nevisIDM Instance to be used for checking terms and conditions.

On Success

Configure the step to execute after the user was successfully authenticated.

On Failure

Configure the step to execute after the authentication failed.

If no step is configured here the process ends.

nevisIDM Administration GUI

The pattern exposes the nevisIDM Administration GUI on a nevisProxy Virtual Host.

The Administration GUI is exposed on /nevisidm/admin.

You can enable the nevisIDM Self Admin GUI under Advanced Settings.

Virtual Host

Assign a Virtual Host which shall serve as entry point.

nevisIDM

References a nevisIDM Instance.

Trust Store

Assign a trust store if you want to validate the server certificate used by nevisIDM. If this not set, the connection is 1-way TLS.

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname of nevisIDM

Key Store

Assign a key store if you want to use 2-way TLS for the connection between nevisProxy and nevisIDM.

Authentication Realm

Mandatory setting to enforce authentication.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Request Validation (ModSecurity)

  • off - no request validation
  • standard - uses ModSecurity OWASP Core Rule Set (CRS) with default paranoia level 1 - Basic security
  • custom - configure Request Validation Settings via Additional Settings
  • log only - uses standard in log only mode

Self Admin GUI

Choose between:

  • enabled - the nevisIDM self admin GUI will be exposed on the path /nevisidm/selfadmin/.
  • disabled - access to the path /nevisidm/selfadmin/ will be blocked.

If you want to provide a self admin interface for end users we recommend to implement your own application and call the nevisIDM REST API instead. This way you can decide which settings to expose to your users and achieve the desired user experience.

REST API Access

Enables REST API access for the NevisIDM web application. As of 2022 May it is only needed by the Terms & Conditions functionality. If Terms & Conditions is not used, then this can be disabled safely.

  • enabled - the REST API will be exposed on the path /nevisidm/api/*.
  • disabled - access to the path /nevisidm/api/* will be blocked.

If the REST API is enabled here, then the use of the nevisIDM REST Service pattern is not needed.

WARNING: if the nevisIDM REST Service pattern is also used, and has different realms or SecToken patterns assigned, then the configuration may lead to a requirement clash or a similar issue

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

  • Authorization Policy to enforce roles or an authentication level.
  • URL Handling to redirect or forward requests.
  • HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

nevisIDM Authorizations

Use the pattern to customize roles for a nevisIDM Instance.

Assign to the nevisIDM Instance using Additional Settings.

Role Management

Add properties for authorizationConfig.properties. If a role not defined in the uploaded file default values will be used for it.

See Assigning IDM roles for details.

You can input the role with or without nevisIdm prefix. For instance, both Root are nevisIdm.Root are supported.

Role Assignment

Add properties for rolesAssignment.properties. If a role not defined in the uploaded file default values will be used for it.

See Data room authorization for details.

You can input the role with or without nevisIdm prefix. For instance, both Root are nevisIdm.Root are supported.

Role Permissions

Add properties for rolesMapping.properties. If a role not defined in the uploaded file default values will be used for it.

See Functional authorization - nevisIDM roles for details.

The following permissions are allowed:

  • ApplicationCreate, ApplicationDelete, ApplicationModify, ApplicationSearch, ApplicationView
  • AuthorizationApplCreate, AuthorizationApplDelete, AuthorizationApplSearch, AuthorizationApplView,
  • AuthorizationClientCreate, AuthorizationClientDelete, AuthorizationClientSearch, AuthorizationClientView
  • AuthorizationCreate, AuthorizationDelete, AuthorizationModify, AuthorizationSearch
  • AuthorizationEnterpriseRoleCreate, AuthorizationEnterpriseRoleDelete, AuthorizationEnterpriseRoleSearch, AuthorizationEnterpriseRoleView
  • AuthorizationUnitCreate, AuthorizationUnitDelete, AuthorizationUnitSearch, AuthorizationUnitView
  • AuthorizationView,
  • BatchJobExecute, BatchJobView
  • ClientApplAssign, ClientApplDelete, ClientApplView
  • ClientCreate, ClientDelete, ClientModify, ClientSearch, ClientView
  • CollectionCreate, CollectionDelete, CollectionModify, CollectionView
  • ConsentView
  • CredentialChangeState, CredentialCreate, CredentialDelete, CredentialModify, CredentialPdfView, CredentialSearch, CredentialView, CredentialViewPlainValue
  • EnterpriseAuthorizationCreate, EnterpriseAuthorizationDelete, EnterpriseAuthorizationModify, EnterpriseAuthorizationSearch, EnterpriseAuthorizationView
  • EnterpriseRoleCreate, EnterpriseRoleDelete, EnterpriseRoleModify, EnterpriseRoleSearch, EnterpriseRoleView
  • EnterpriseRoleMemberCreate, EnterpriseRoleMemberDelete, EnterpriseRoleMemberSearch
  • EntityAttributeAccessOverride
  • GenerateReport
  • HistoryView
  • LoginIdOverride, LoginIdModify
  • PersistentQueueView, PersistentQueueDelete
  • PersonalQuestionCreate, PersonalQuestionDelete, PersonalQuestionModify, PersonalQuestionView, PersonalQuestionSearch
  • PolicyConfigurationCreate, PolicyConfigurationDelete, PolicyConfigurationModify, PolicyConfigurationSearch, PolicyConfigurationView
  • ProfileArchive, ProfileCreate, ProfileDelete, ProfileModify, ProfileSearch, ProfileView
  • DeputyCreate, DeputyDelete
  • PropertyAllowedValueCreate, PropertyAllowedValueDelete, PropertyAllowedValueModify, PropertyAllowedValueSearch, PropertyAllowedValueView, PropertyAttributeAccessOverride
  • PropertyView, PropertyCreate, PropertyDelete, PropertyModify, PropertySearch
  • PropertyValueCreate, PropertyValueDelete, PropertyValueModify, PropertyValueSearch, PropertyValueView
  • RoleCreate, RoleDelete, RoleModify, RoleSearch, RoleView
  • SearchResultsExport
  • SelfAdmin
  • TemplateView, TemplateCreate, TemplateDelete, TemplateModify, TemplateStore
  • TemplateTextCreate, TemplateTextDelete, TemplateTextModify, TemplateTextView
  • TermsCreate, TermsDelete, TermsModify, TermsView
  • UnitCreate, UnitCreateTopUnit, UnitDelete, UnitModify, UnitSearch, UnitView
  • UnitCredPolicyCreate, UnitCredPolicyDelete, UnitCredPolicyView
  • UserArchive, UserCreate, UserDelete, UserModify, UserSearch, UserView
  • UserCreateTechUser, UserModifyTechUser, UserDeleteTechUser, UserArchiveTechUser

nevisIDM Check User Credentials

Checks if user has credentials. There are possible follow-up slot for patterns if

  • no credential found
  • at least one, but not all Credential found
  • all Credential found

It checks against all credentials, which specifically are not mentioned to not to check against.

The pattern is experimental and may be improved in future releases. We are looking forward to your feedback and requirements.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

No credential found

Configure the step to execute if the user has no credential from credential types defined in Credential Types. If no step is configured here the process ends with AUTH_DONE.

Any credential found

Configure the step to execute if the user has at least one credential from credential type selected in Credential Types, but nit from all credential type. If no step is configured here the process ends with AUTH_DONE.

All credential found

Configure the step to execute if the user has at least one credential from all type selected in Credential Types. If no step is configured here the process ends with AUTH_DONE.

Credential Types

Credential types which existence for the user should be checked.

Possible values:

  • PASSWORD
  • CERTIFICATE
  • SECURID
  • TICKET
  • SAFEWORDUSER
  • OTP
  • TEMPSTRONGPASSWORD
  • GENERIC
  • KERBEROS
  • MTAN
  • VASCO
  • PUK
  • URLTICKET
  • DEVICEPASSWORD
  • MOBILESIGNATURE
  • SAMLFEDERATION
  • SECURITYQUESTIONS
  • CONTEXTPASSWORD
  • OATH
  • FIDO_UAF
  • RECOVERY_CODE
  • FIDO2

nevisIDM Client

Assign this pattern to a nevisIDM Instance via Additional Settings to create a client at startup.

Note that removing this pattern won't remove the client from nevisIDM.

External ID

External ID of the new client.

Client Name

The name of the client.

Client Display Names

The name of the client in different languages.

The format is:

  • two letter language code in lower case
  • separator characher: = or :
  • the client name in that language

For example:

de:Beispiel-Client
fr:Exemple de client

Remarks

Any other additional information about the client.

nevisIDM Client Certificate Authentication

Ask the user to send a client certificate.

The step uses an IdmX509State to look up the user in nevisIDM, based on the value of the Certificate credential.

If no client certificate is provided, or no user is found for this certificate, an error will be shown.

The following generic label is used: error.login.1

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Assign an optional step to execute after successful authentication.

nevisIDM Connector

Use to connect to an existing nevisIDM instance.

Use the pattern only when the instance is not set up by the project.

Ensure that the SecToken trust store of the instance allows the SecToken signers used in this project.

Connection URL(s)

Enter URL(s) to connect to your nevisIDM instance.

The path must be omitted.

Only scheme https:// is allowed.

The scheme is optional which means that you can enter simple host:port pairs (1 per line).

Kubernetes

This setting is used when deploying to Kubernetes only.

Choose between:

  • disabled: instance running on a VM.

  • same_namespace: service running in the same cluster and namespace.

  • other_namespace: service running in the same cluster but in another namespace.

  • other_cluster: service running in another cluster.

Namespace

Enter the Kubernetes namespace.

Configuration is required when Kubernetes is set to other_namespace.

nevisIDM Connector for Generic Authentication

Generates an AuthState named nevisIDM_Connector, which configures the connection to the assigned nevisIDM instance.

You can use the connection in the Generic authentication pattern by adding the following element:

<propertyRef name="nevisIDM_Connector"/>

nevisIDM

The nevisIDM instance that the generated AuthState should connect to.

Generic Authentication Patterns

Any generic Auth pattern that should have access to the generated AuthState.

nevisIDM Custom Property

Assign the pattern to a nevisIDM Instance to create a custom property.

Note that removing the pattern does not remove the property from nevisIDM. You can do this using SQL instead.

Property Name

Enter name for the property definition file.

Technical name of the property. The name has to be unique among the properties of the same scope and within the same client.

Property Scope

Select the type of property:

  • USER_GLOBAL: all users have this property
  • CREDENTIAL_GENERIC_GLOBAL: all Generic credentials have this property
  • UNIT_GLOBAL: all units have this property

Uniqueness Scope

If set then values stored in the property must be unique within the configured scope.

  • ABSOLUTE: The property's values have to be unique overall. Two property values with the same content must not exist.

Client External ID

Enter clientExtId for the property definition file.

If set, the property becomes specific to the referred client. Otherwise, the property is client-independent.

Maximum Length

Enter maxLength for the property definition file.

Defines the maximum length of the property value.

Regular Expression

Enter regex for the property definition file.

The defined regular expression will restrict the possible values that can be assigned to the property. If a value is entered, it will be checked against the specified pattern to ensure it meets the criteria.

Some examples of how regular expressions can be used for common data types:

Email address:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Telephone number in the format +[country code] (XXX) XXX-XXXX:

^\+\d{1,3}\s?\(\d{3}\)\s?\d{3}-\d{4}$

Social Insurance Number (SIN) in the format XXX-XX-XXXX:

^\d{3}-\d{2}-\d{4}$

URL in the format:

(https:\/\/www\.|http:\/\/www\.|https:\/\/|http:\/\/)?[a-zA-Z0-9]{2,}(\.[a-zA-Z0-9]{2,})(\.[a-zA-Z0-9]{2,})?

The regex will be escaped for JSON if required.

Description

The description field in the property definition file allows you to provide a clear and informative description of the custom property. This description will be valuable for understanding the purpose, expected values, or any other relevant information about the property.

The description will be escaped for JSON if required.

Modification Access

Possible settings:

  • READ_WRITE: Input is possible for the if previous value was stored.
  • READ_ONLY: Field is read only.
  • OFF: Field is not updatable and property is not displayed GUI.

Users with AccessControl.PropertyAttributeAccessOverride can edit these field regardless of this settings.

Creation Access

Possible settings:

  • READ_WRITE: Input is possible for the if no previous value was stored.
  • READ_ONLY: Field is read only.
  • OFF: Field is not updatable and property is not displayed GUI.

Users with AccessControl.PropertyAttributeAccessOverride can edit these field regardless of this settings.

nevisIDM Database

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 and Oracle and PostgresSQL.

We recommend to use MariaDB as it is supported by all Nevis components that have a database.

Note: PostgresSQL database is only experimental configuration.

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.

Root Credential

Enter the name of a Kubernetes secret which contains the user and password of a database root account.

Required in Kubernetes deployment when Advanced Settings / Database Management is to complete or schema.

This is the default behaviour in Kubernetes.

With complete the secret should contain the following:

username: <root-user
password: <root-password>

If the Database Management is set to schema the root user can be omitted, but the application and schema user has to be specified:

ownerUsername: <some-username>
ownerPassword: <some-password>
appUsername: <some-username>
appPassword: <some-password>

If used with complete the app and owner users will be created with the credentials specified in the secret.

Due to the usage of schemas, it is recommended to create a separate Kubernetes secret for each database pattern with the app and owner credentials when using Oracle or PostgreSQL.

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

Enables SSL/TLS in a specific mode. The following values are supported:

  • disabled: Do not use SSL/TLS (default)
  • trust: Only use SSL/TLS for encryption. Do not perform certificate or hostname verification. This mode is not safe for production applications but still safer than disabled.
  • verify-ca: Use SSL/TLS for encryption and perform certificates verification, but do not perform hostname verification.
  • verify-full: Use SSL/TLS for encryption, certificate verification, and hostname verification.

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.

Database Management

The pattern can set up the database, and it's schema when deploying to Kubernetes.

The complete option, on top of handling the schema migration, will do the initial database preparation like creating the actual database or tablespace in case of oracle, as well as creating the required database users.

The schema option will skip the initial preparation and will only take care of the actual schema migration. This requires the schema owner and the application user credentials to be present in the root credential secret. The root user information can be omitted with this option.

You can select disabled here to opt out. In this case you have to create and migrate the database schema yourself.

This feature is set to recommended by default which aims for the most convenient solution based on the deployment type. In case of Kubernetes deployments, it uses complete. In a classical VM deployment, it will use schema if the pattern allows setting Schema User and Schema Password, otherwise it's 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.

nevisIDM Generic Batch Job

Configure a batch job for nevisIDM using the XML syntax described in the technical documentation.

Use the pattern only when there is no dedicated pattern for your batch job.

Assign the pattern to a nevisIDM Instance using Additional Settings.

Job(s)

Add configuration of a bean which configures your batch job.

The basic syntax is as follows:

<bean id="someJobId" class="org.springframework.scheduling.quartz.JobDetailFactoryBean">
<property name="description" value="Some job description"/>
<property name="durability" value="true"/>
<property name="jobClass" value="some.job.Class"/>
<property name="jobDataMap">
<bean class="org.quartz.JobDataMap">
<constructor-arg>
<map>
<entry key="someJobParam" value="some value"/>
</map>
</constructor-arg>
</bean>
</property>
</bean>

Trigger(s)

Add configuration of a bean which acts as a trigger for job execution.

Execute every 24 hours:

<bean id="someTriggerId" class="org.springframework.scheduling.quartz.SimpleTriggerFactoryBean">
<property name="description" value="Some description shown in nevisIDM Admin GUI"/>
<property name="jobDetail" ref="someJobId"/> <!-- must be provided via Job(s) -->
<property name="repeatInterval" value="86400000"/> <!-- 1 day in ms -->
<property name="misfireInstructionName" value="MISFIRE_INSTRUCTION_RESCHEDULE_NEXT_WITH_EXISTING_COUNT"/>
</bean>

Execute once a day at midnight (cron expression):

<bean id="someTriggerId" class="org.springframework.scheduling.quartz.CronTriggerFactoryBean">
<property name="description" value="Some description shown in nevisIDM Admin GUI"/>
<property name="jobDetail" ref="someJobId"/> <!-- must be provided via Job(s) -->
<property name="cronExpression" value="0 0 0 * * ?"/>
</bean>

Custom Batch Job JAR(s)

Upload JAR file(s) for custom batch jobs.

Note that batch jobs which call the nevisIDM business layer are not supported by Nevis. Please call the nevisIDM REST API only.

nevisIDM Instance

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:

  1. Rename the pattern in the GUI.
  2. Rename the instance directory and associated systemd files on the deployment hosts.
  3. 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 don't 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.

Frontend Key Store

Assign the Key Store provider for the HTTPs endpoint. If no pattern is assigned a Key Store will be provided by the nevisAdmin 4 PKI.

Frontend Trust Store

Assign the Trust Store provider for the HTTPs endpoint. If no pattern is assigned the Trust Store will be provided by the nevisAdmin 4 PKI.

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.

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 SSL/TLS Mode

Choose between:

  • disabled - SSL/TLS is disabled. The SMTP Trust Store is not used.
  • STARTTLS - uses the STARTTLS command (see RFC 2487) to switch to SSL/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.

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.

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.

nevisIDM JMS Queues

Configures a nevisIDM Instance to publish events into JMS queues.

Remote Provisioning Queue

NevisIDM JMS Queue to which Provisioning messages should be sent.

Only accepts URIs starting with amqp, amqps or Endpoint=sb. Validates only URIs with amqp or amqps schemes.

Remote Expiry Queue

NevisIDM JMS Queue to which Expiry messages should be sent.

Only accepts URIs starting with amqp, amqps or Endpoint=sb. Validates only URIs with amqp or amqps schemes.

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

NevisIDM JMS Queue to which Dead Letter messages should be sent.

Only accepts URIs starting with amqp, amqps or Endpoint=sb. Validates only URIs with amqp or amqps schemes.

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

You should add a CA certificate, and then use a PEM Trust Store to provide it.

nevisIDM Log Settings

Change log configuration for nevisIDM.

Default Log Level

Change the level of the root logger. This impacts all logging apart from Log Levels.

Note that Syslog appenders have a threshold which ensures that only INFO, WARN, or ERROR messages are forwarded.

Log Levels

Configure log levels.

See the nevisIDM Technical Documentation, chapter nevisIDM log levels (file: logging.yml) for details.

Hint: If you only change log levels nevisAdmin 4 does not restart the component in classic VM deployment. The new log configuration will be reloaded within 60 seconds after deployment.

The default configuration is:

ch.nevis.idm.batch.jobs = INFO
ch.nevis.idm.standalone = INFO

Examples:

ch.adnovum.nevisidm.service.properties = INFO
ch.nevis.ninja = DEBUG

Rotation Type

Select log rotation type.

Choose between:

  • size - defines the maximum file size before the log files are rolled over
  • time - defines the time span after which logs are rolled over

If you rotate by time we recommend you monitor the disk usage as log files can be huge.

Note: a combination of size and time based log rotation is not supported.

Max Backup Files

Maximum number of backup files to keep in addition to the current log file.

This setting applies to application.log and batch.log only. The audit.log is rotated on a daily basis.

Max File Size

Maximum allowed file size (in bytes) before rolling over.

Suffixes "KB", "MB" and "GB" are allowed. 10KB = 10240 bytes, etc.

Note: This parameter only applies to application.log and batch.log (as audit.log is configured with DailyRollingFileAppender).

Rotation Interval

Rotation interval after which log files are rolled over.

This configuration is not used when Rotation Type is set to size.

Choose between:

  • daily - the postfix of rotated files will be .%d{yyyy-MM-dd}
  • hourly - the postfix of rotated files will be .%d{yyyy-MM-dd-HH}

Log Format

Log4j 2 log format for the default SERVER logs.

Note: not relevant when Log Targets is set to syslog.

Syslog Format

Log4j 2 log format for the SERVER SYS logs.

Note: not relevant when Log Targets is set to default.

Regex Filter

If set, messages for application.log which match the given regular expression won't be logged.

The regular expression must match the entire line. For instance, you may use the following format to match some text:

.*some text.*

Log Type

Configure audit logging capability of nevisIDM.

  • When JSON (default) is selected, nevisIDM will write audit entries in JSON format.
  • When plain is selected, nevisIDM will write audit entries as plain log lines. This setting is deprecated and may be removed in a future release.
  • When disabled is selected, nevisIDM will not log audit entries at all.

In classic VM deployments the log target is /var/opt/nevisidm/<instance>/logs/audit.log. In Kubernetes and when JSON is selected the log messages are written to the pod log with the prefix [audit.log].

If you deploy nevisIDM to multiple hosts (multi-instance setup), the audit logging will only be enabled on the first host.

Log Format

Log4j 2 log format for the default SERVER logs.

Note: not relevant when Log Targets is set to syslog.

Syslog Format

Log4j 2 log format for the SERVER SYS logs.

Note: not relevant when Log Targets is set to default.

Log Format

Log4j 2 log format for the default SERVER logs.

Note: not relevant when Log Targets is set to syslog.

Log Targets

Select the type of appender.

In Kubernetes the default appender writes to system out so that log messages appear in the docker logs.

Choose between:

  • default - log to default target
  • default + syslog - log to default target and forward to a Syslog server
  • syslog - forward to a Syslog server only

Syslog Host

Defines where to send logs to via syslog.

This configuration is used only when syslog forwarding is enabled (see Log Targets).

The syslog facility is localhost3 and the threshold is INFO.

nevisIDM Password Create

Creates a password credential for the current user.

This pattern requires that the user has been set in the session up already.

For instance, put a nevisIDM User Lookup pattern before this step.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Assign a step to continue with after successfully creating the password credential.

On Password Exists

If the user already has a password credential and error will occur.

You can assign a step here to handle this case.

State after creation

The state which the credential is in when created. Options:

  • INITIAL
  • ACTIVE
  • DISABLED

Show Policy Violations

If set to enabled then after failed credential creation displays violated policies.

nevisIDM Password Login

Login to nevisIDM with username and password.

The step is intended to be used as a first factor in the Initial Authentication Flow of an Authentication Realm.

To support login using email, store the email in the Login ID field of the user.

Authentication is based on the default password policy of the selected client. See the nevisIDM Technical Documentation on how to adapt the policy.

On successful authentication, the UserId of the session is set to the Ext ID of the nevisIDM user.

For Web Application, an initial redirect (to ?login) is performed and a login GUI is shown. Technical clients calling a REST Service or SOAP Service may use basic authentication and send the credential upfront.

Double-check the URL you are calling as nevisProxy also responds with a redirect if no servlet can be found otherwise (trailingSlashRedirect).

The step also supports enforced password change, for expired passwords, and provides password reset, for users who forgot their password.

nevisIDM

Reference a nevisIDM Instance to be used for the username / password authentication.

On Success

Configure the step to execute after successful authentication.

If no step is configured here the process ends and the user will be authenticated.

Buttons

Assign an Dispatcher Button to add a button which points to a different authentication step.

User Attributes

Enter user attributes to fetch from nevisIDM.

Important attributes are:

  • extId - unique ID of the user in nevisIDM
  • loginId - name which could be used to login (instead of email)
  • firstName
  • name - surname
  • email
  • mobile
  • language - language stored for user (can differ from Accept-Language sent by the browser)

For a complete list please check the documentation of IdmGetPropertiesState.

Some attributes (e.g. extId, email, and mobile) are always fetched as they are required by standard authentication steps.

The attributes will be stored in the user session as ch.nevis.idm.User.<attribute>.

Attributes may be used in sub-sequent authentication steps or included in application access tokens (e.g. NEVIS SecToken, SAML Token, or JWT Token).

For instance, use them in a Generic Authentication Step via the expression ${sess:ch.nevis.idm.User.<attribute>}.

Password Reset

Enables the password reset process.

The password reset process works as follows:

  • The user has to enter his login ID or email.
  • An email with a link be sent to the user.
  • The user has to click the link in the mail to set a new password.

A link will be added to the login page. Users may click this link if they have forgotten their password to request a new password.

The link text can be changed on the Realm pattern by setting translations for the label pwreset.info.linktext.

Entry Path

The path prefix of the links for the password forgotten process.

Example: given a domain www.adnovum.ch and the value /pwreset/, all password forgotten steps will use the base path www.adnovum.ch/pwreset/.

URL Ticket Policy Name

Enter the name of a nevisIDM URL Ticket policy to use for the URL Ticket that is created at the beginning of the password reset process.

If nothing is configured here the default URL Ticket policy will be used.

Among others, the policy defines how the link is communicated to the user (e.g. by sending an email) and sets the expiration.

You can create additional policies via the nevisIDM Admin GUI or via SOAP / REST API.

Require Password Confirmation

Select the behaviour of password reset and the form of the password reset screen. If

  • enabled: displays password confirmation field on password reset screen which is required to be filled in for password to be reset.
  • disabled: leaves out field on password reset screen and password can be reset with filling out password field only.

Email Sent Redirect

Where to redirect to once the password reset ticket has been generated.

  • root: to the domain root (/) on this Virtual Host
  • referrer: to the initial URL requested by the client
  • custom: to a custom path or URL as configured by Custom Email Sent Redirect

Note that the referrer will always be a page requiring authentication, hence it will basically redirect to the login page.

Custom Email Sent Redirect

Enter a URL, path, or nevisAuth expression which defines where to redirect to after the ticket has been created (and sent to the user via email).

Successful Change Redirect

Where to redirect to once the password reset is successfully completed.

See the "Email Sent Redirect" property for more information about the possible values.

Note that in this case, referrer can be very useful as it will redirect the client straight to the page he initially wanted to access before he started the password forgotten process.

Custom Successful Change Redirect

Enter a URL, path, or nevisAuth expression which defines where to redirect to after the new password has been set.

Separate Username / Password Screens

Set to enabled to ask for the username and password in two separate screens.

Show Client Input Field

Enable this to allow the user to enter the name of the Client (tenant) when logging in to nevisIDM.

If disabled, the input field is not shown and the Client Default is used.

Login Type

Define how to look up the user.

Choose between:

  • LOGINID - lookup user by loginId attribute.
  • EMAIL - lookup user by email attribute.
  • AUTO - depending on what has been entered, nevisIDM tries to look up the user by email or loginId attribute.

We recommend to use LOGINID as it is the most efficient way to look up users and has no side effects. This can even work when users enter their email as you can store the email in the loginId attribute as well.

For AUTO and EMAIL to work nevisIDM has to be configured accordingly. You either have to:

  • Set authentication.loginWithEmail.enabled=true in the Client policy. Policies cannot be configured using patterns. You can change them on the nevisIDM Admin GUI.
  • Set application.feature.emaillogin.enabled=true in nevisidm-prod.properties. Use the Generic nevisIDM Instance Settings pattern for this.

Authentication Level

Set an authentication level if authentication of this step is successful. The level is relevant only if there are is an Authorization Policy assigned to applications.

Re-enter Expired Password

When the password is expired or has been reset by an administrator, the user is forced to set a new password.

Set this drop-down to enabled to force the user to enter the old password again when this happens.

Legacy LitDict Mode

In legacy mode policy violations are displayed using 1 GUI element.

You can use enabled here until November 2021 when this mode will be removed.

Reset Locked Password

Defines whether it is possible to reset locked passwords or not.

  • If enabled, it is possible to reset locked passwords as well. In this case, only disabled passwords cannot be reset.
  • If disabled, it is only possible to reset active passwords.

Form Encryption

Set to enable form encryption.

This feature is still experimental in nevisAdmin 4 and has been added to this pattern as a preview.

The default template includes the required JavaScript (e2eenc.js) to perform client-side encryption of the form values.

User Properties

Enter user properties to fetch from nevisIDM and store in the user session.

Properties must be created in the nevisIDM via SQL.

Unit Attributes

Enter unit attributes to fetch from nevisIDM. Enter 1 attribute per line.

The following unit attributes are supported:

  • extId, state, name
  • displayName, displayAbbreviation, location, description, hname, localizedHname
  • ctlCreDat, ctlCreUid, ctlModDat, ctlModUid

Unit Properties

Enter unit properties to fetch from nevisIDM. Enter 1 property per line.

The properties must have scope onUnitGlobal. The property name must be exactly as defined in nevisIDM. Otherwise, the property value will never be written into the session.

Use Default Profile

Should in the Authentication flow assume default profile is selected if the user has multiple profiles, or should it display a selection dialog for the user.

nevisIDM Prune History Job

Assign to a nevisIDM Instance to configure a batch job which cleans up old history data.

Retention

Define how long history data shall be kept in days.

Example: 30d

The minimum value is 1d. The maximum value is 1024d.

Cron Expression

Enter a cron expression which defines when this job will be executed.

Cron expressions consist of 6 required fields and one optional field separated by white space.

The field order is:

  1. Seconds
  2. Minutes
  3. Hours
  4. Day-of-Month
  5. Month
  6. Day-of-Week
  7. Year (optional)

Cron expression can be complex and this pattern only validates the length. The most important wildcards are:

  • * is used to specify all values. For example, * in the minute field means every minute.
  • ? is allowed for the day-of-month and day-of-week fields. It is used to specify no specific value.
  • - is used to specify ranges.

Further information about the supported syntax can be found in the javadoc of org.quartz.CronExpression.

Examples:

  • 0 0 0 * * ?: fires every midnight.
  • 0 0/30 8-9 5,20 * ?: fires every half hour between the hours of 8 am and 10 am on the 5th and 20th of every month.
  • 0 30 10-13 ? * WED,FRI: fires at 10:30, 11:30, 12:30, and 13:30, on every Wednesday and Friday.

Skip List

Comma-separated list of versioned tables (which are used to provide history data) to be ignored by the prune history job and left with their original content.

Possible values (Any combination of the following):

  • tidma_application_v
  • tidma_authorization_appl_v
  • tidma_authorization_client_v
  • tidma_authorization_erole_v
  • tidma_authorization_unit_v
  • tidma_authorization_v
  • tidma_cert_info_v
  • tidma_client_application_v
  • tidma_client_v
  • tidma_consent_v
  • tidma_cred_login_info_v
  • tidma_credential_v
  • tidma_dict_entry_v
  • tidma_dict_entry_value_v
  • tidma_enterprise_auth_v
  • tidma_enterprise_role_v
  • tidma_erole_member_v
  • tidma_fido2_v
  • tidma_fido_uaf_v
  • tidma_mobile_signature_v
  • tidma_oath_v
  • tidma_personal_answer_v
  • tidma_personal_question_v
  • tidma_policy_configuration_v
  • tidma_policy_parameter_v
  • tidma_profile_v
  • tidma_property_allowed_val_v
  • tidma_property_v
  • tidma_property_value_v
  • tidma_role_v
  • tidma_saml_federation_v
  • tidma_template_collection_v
  • tidma_template_text_v
  • tidma_template_v
  • tidma_terms_application_v
  • tidma_terms_url_v
  • tidma_terms_v
  • tidma_unit_cred_policy_v
  • tidma_unit_v
  • tidma_user_login_info_v
  • tidma_user_v

For further information about historical tables visit Versioned DB tables .

nevisIDM REST Service

Set up access to nevisIDM REST service on a nevisProxy Virtual Host.

The nevisIDM REST Service is exposed as: /nevisidm/api.

Virtual Host

Assign a Virtual Host which shall serve as entry point.

nevisIDM

References a nevisIDM Instance.

Trust Store

Assign a trust store if you want to validate the server certificate used by nevisIDM. If this not set, the connection is 1-way TLS.

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname of nevisIDM

Key Store

Assign a key store if you want to use 2-way TLS for the connection between nevisProxy and nevisIDM.

Authentication Realm

Mandatory setting to enforce authentication.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

  • Authorization Policy to enforce roles or an authentication level.
  • URL Handling to redirect or forward requests.
  • HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

nevisIDM SOAP Service

Using the pattern, you can set up access to the nevisIDM SOAP APIs on a nevisProxy Virtual Host.

The nevisIDM SOAP APIs are exposed on /nevisidm/services.

Virtual Host

Assign a Virtual Host which shall serve as entry point.

nevisIDM

References a nevisIDM Instance.

Trust Store

Assign a trust store if you want to validate the server certificate used by nevisIDM. If this not set, the connection is 1-way TLS.

Hostname Validation

Enable to verify that the hostname on the certificate presented by the backend matches the hostname of nevisIDM

Key Store

Assign a key store if you want to use 2-way TLS for the connection between nevisProxy and nevisIDM.

Authentication Realm

Mandatory setting to enforce authentication.

Application Access Token

Propagate a token to the backend application. The token informs the application about the authenticated user.

For instance, assign NEVIS SecToken if the application uses Ninja or SAML Token for applications which are able to consume SAML Responses.

Additional Settings

Assign add-on patterns to customize the behaviour of this service.

Example use cases:

  • Authorization Policy to enforce roles or an authentication level.
  • URL Handling to redirect or forward requests.
  • HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

nevisIDM Second-Factor Selection

This authentication step checks the credentials of the user to determine a second factor for authentication.

If the user has multiple supported credentials, a selection dialog is shown.

The following labels are used in that dialog and you should change their translations:

  • method.mtan.label - en: mTAN Code
  • method.otp.label - en: OTP (One-Time Password)
  • method.oath.label - en: OATH Authenticator App
  • method.fido.label - en: Mobile Authentication
  • method.fido2.label - en: FIDO 2
  • method.recovery.label - en: Recovery Codes

You can use the step within an Authentication Realm as follows:

  • in Initial Authentication Flow, after first-factor authentication
  • in Session Upgrade Flows

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

OTP card

Assign a step which may be selected when the user has an OTP card credential.

Note that OTP card credentials may be used for various authentication methods (e.g. a one-time password list or VASCO Digipass devices).

OATH (TOTP)

Assign a step which may be selected when the user has an OATH (TOTP) credential.

OATH (TOTP) credentials may be used for second factor authentication using an authentication app, e.g. Google Authenticator.

mTAN

Assign a step which may be selected when the user has an mTAN credential.

You can assign any step here but we recommend to use the Mobile TAN pattern.

The session variable user.mobile will contain the mobile number from the mTAN credential.

FIDO UAF Authenticator

Assign a step which may be selected when the user has an FIDO UAF Authenticator credential.

For instance, assign the Out-of-band Mobile Authentication pattern.

FIDO2 Authenticator

Assign a step which may be selected when the user has a FIDO2 Authenticator credential.

Assign a FIDO2 Authentication pattern here.

Recovery code

Assign a step which may be selected when the user has a recovery codes credential.

For instance, assign a Generic Authentication Step pattern.

Not Found

Assign a step to continue with if the user does not have any supported credential.

Configuration is optional but we recommend to assign a step to handle the missing second-factor credential case. For instance, you may assign the following steps:

  • User Information: to show an error message and terminate the authentication flow.
  • OATH Onboarding: to register an authenticator app which supports OATH Time-based One-Time Password algorithm (TOTP).
  • FIDO2 Onboarding: to register a FIDO2 authenticator such as a mobile device or USB security key.

nevisIDM Terms & Conditions Acceptance

nevisIDM Terms & Conditions Acceptance.

Use as a follow-up step in the Initial Authentication Flow of an Authentication Realm.

This step will show the user all the terms and conditions set for the user in nevisIDM to accept. Acceptance will be stored in nevisIDM.

LitDict keys for updating are: info.terms.welcome, title.terms

Background information can be found in the nevisIDM Developer Guide.

For information about how terms & conditions are supposed to checked in nevisAuth check Developer Use Cases.

For the data model read this chapter.

nevisIDM

Reference a nevisIDM Instance to be used for checking terms and conditions.

On Success

Configure the step to execute after the user has accepted all terms and conditions.

If no step is configured here the process ends and the user will be authenticated.

nevisIDM URL Ticket Consume

Provides an endpoint on a Virtual Host to consume URL tickets. The request has to contain a query parameter x containing the ticket code.

Before the ticket is validated a Gui is shown. The Gui has an info text with label info.url_ticket.welcome and a continue button.

This Gui prevents that clients consume the ticket by calling the URL (e.g. to render a preview), before the user even has a chance to click the link.

When the ticket is valid, the step assigned to On Success will be executed.

Note that when a URL Ticket credential is created for a nevisIDM user, the associated URLTicket policy defines how the link is generated and communicated.

With sendingMethod=Email the user will receive an email.

Your support team can create URL tickets using the nevisIDM Admin GUI. This requires that the policy sets urlPrefix so that the link can be generated.

URL tickets are often generated during an authentication flow. As of Aug 2022 there is no high-level step to create URL tickets, use Generic Authentication Step instead.

Virtual Host

Assign a Virtual Host.

Frontend Path(s)

Enter frontend path(s) which should be handled.

Authentication Realm

Assign an Authentication Realm.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Assign an authentication step which shall be executed when the URL ticket is valid.

Note: this pattern does not provide any content on the exposed Frontend Path(s) and does not ensure that the caller is redirected when the authentication flow terminates.

Thus, please take appropriate measures at the end of the flow to avoid a 404 error. For instance, you may trigger a redirect at the end of your flow, or assign an URL Handler to Additional Settings.

On Expired

Assign an authentication step to execute when the URL ticket is expired.

If not set a screen with title.url_ticket and error.url_ticket.expired will be shown in that case.

On Disabled

Assign an authentication step to execute when the URL ticket or user is disabled.

If not set a screen with title.url_ticket and error.user_or_url_ticket.disabled will be shown in that case.

On Not Found

Assign an authentication step to execute when the URL ticket is not found.

If not set a screen with title.url_ticket and error.url_ticket.not_found will be shown in that case.

Allowed HTTP Methods

Define the allowed HTTP methods.

If not configured, all HTTP methods are allowed.

Additional Settings

Assign add-on patterns to customize the behaviour of this authentication service.

Example use cases:

  • URL Handling with phase AFTER_AUTHENTICATION to redirect after the authentication flow completes.
  • Access Restriction to restrict access based on source IPs.
  • HTTP Header Customization to add, replace, or remove HTTP headers in requests or responses.

nevisIDM User Create

Create a user in nevisIDM.

This pattern can only create the user but does not create any credentials (e.g. password). You need additional steps to give the user appropriate credentials.

Note that when the user is created, nevisIDM policies may be applied.

For instance, you can give your user certain roles by setting defaultAuthorizations in the profile policy. You can configure this policy in the nevisIDM Admin GUI.

The pattern is experimental and may be improved in future releases. We are looking forward to your feedback and requirements.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Define how to continue after user creation.

On Failure

Define how to continue after user creation, if it was unsuccessful.

Mandatory User Attributes

Define which attributes will always be set for the user.

The value can be constant or determined by a nevisAuth or EL expression. User creation will fail when the value is empty.

Which attributes must be provided depends on policy configuration in nevisIDM.

How to best determine the value depends on preceeding authentication states and the (session) variables they produce.

For instance, let's assume that the email is stored in a session variable called email, the first name in firstname, and the last name in name. You can then use:

email: ${sess:email}
loginId: ${sess:email}
name: ${sess:name}
firstName: ${sess:firstname}

Optional User Attributes

Define which attributes are optional and how to provide them.

Example:

firstName: ${sess:given_name}
name: ${sess:family_name}
country: ${sess:country}

Client ID

Enter the client ID where the user shall be created.

Unit ID

Enter the unit ID where the user shall be created.

Login ID

Define how the loginId is set:

  • auto: the loginId is generated. loginIdGenerator.enabled=true must be set in the client policy. This can be achieved via the nevisIDM Administration GUI.
  • email: use the email for the loginId. The email must be provided via Mandatory User Attributes.
  • value: the loginId must be provided via Mandatory User Attributes.

nevisIDM User Login Info Checker

Checks if user has previously. There are possible follow-up slot for patterns if

  • no previous login
  • previously logged in

It checks only for successful previous login.

The pattern is experimental and may be improved in future releases. We are looking forward to your feedback and requirements.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On User Previously Logged In

Configure the step to execute if the user has previously logged in. If no step is configured here the process ends with AUTH_DONE.

On User Never Logged In

Configure the step to execute if the user never logged in. If no step is configured here the process ends with AUTH_DONE.

nevisIDM User Login Info Update

Update a user's login info in nevisIDM.

The pattern is experimental and may be improved in future releases. We are looking forward to your feedback and requirements.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Configure the step to execute after the user's login info is updated. If no step is configured here the process ends with AUTH_DONE.

On Failure

Assign a step to execute if the nevisIDM is not able to update a User's login info.

For instance, you may assign the following steps:

  • User Information: show an error message and terminate the authentication flow.

nevisIDM User Lookup

Look up a user from nevisIDM by Login ID.

You can use the pattern in combination with other means to check user credentials.

For instance, use in front of Authentication Cloud for passwordless authentication.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

Authentication Mode

Select interactive to prompt the user to enter a Login ID.

An input form will be shown when the query or POST parameter isiwebuserid is missing or the user is not found in nevisIDM (and On User Not Found is not set).

Select pass-through to look up the user based on Login ID Source.

In this mode no input form will be shown. Instead, a 403 response will be generated if the user is not found (and On User Not Found is not set).

Login ID Source

Enter a nevisAuth expression for the login ID which is used to look up the user.

Supported and required in authentication mode pass-through only.

Examples

  • ${inargs:isiwebuserid}

On Success

For security reasons nevisIDM User Lookup alone is not sufficient to authenticate the user.

The authentication flow should contain another step which checks credentials of the user and sets an Authentication Level.

Thus, it is required to assign a step here which will be executed after the user has been looked up from nevisIDM.

Examples:

  • Authentication Cloud
  • Mobile TAN (mTAN)
  • Generic Authentication Step

On User Not Found

Assign a step to execute in the following error cases:

  • User not found (1)
  • User archived or disabled (98)

The variable lasterror is not cleared from the notes and thus an error message may be displayed in the next GUI which is rendered by nevisAuth.

This setting does not apply to technical errors. In case the call to nevisIDM fails the GUI will be shown (again) and the the message error_99 will be displayed.

Buttons

Assign a Dispatcher Button to add button(s) which points to a different authentication step.

Show Client Input Field

Enable this to allow the user to enter the name of the Client (tenant) when logging in to nevisIDM.

If disabled, the input field is not shown and the Client Default is used.

Client ID

The source of the client’s external ID.

Used only when Show Client Input Field is set to disabled.

Set either this or Client Name.

Client Name

The source of the client’s name.

Used only when Show Client Input Field is set to disabled.

Set either this or Client ID. When neither is set then Default is used.

User Attributes

Enter user attributes to fetch from nevisIDM.

Important attributes are:

  • extId - unique ID of the user in nevisIDM
  • loginId - name which could be used to login (instead of email)
  • firstName
  • name - surname
  • email
  • mobile
  • language - language stored for user (can differ from Accept-Language sent by the browser)

For a complete list check the documentation of IdmGetPropertiesState.

Some attributes (e.g. extId, email, and mobile) are always fetched as they are required by standard authentication steps.

The attributes will be stored in the user session as ch.nevis.idm.User.<attribute>.

Attributes may be used in sub-sequent authentication steps or included in application access tokens (e.g. NEVIS SecToken, SAML Token, or JWT Token).

For instance, use them in a Generic Authentication Step via the expression ${sess:ch.nevis.idm.User.<attribute>}.

User Properties

Enter user properties to fetch from nevisIDM and store in the user session.

Properties must be created in the nevisIDM via SQL.

Unit Attributes

Enter unit attributes to fetch from nevisIDM.

Possible attributes are:

  • extId - unique ID of the unit in nevisIDM
  • state - state of the unit in nevisIDM
  • name
  • displayName
  • displayAbbreviation
  • location
  • description
  • hname
  • localizedHname
  • ctlCreDat
  • ctlCreUid
  • ctlModDat
  • ctlModUid

For a complete list check the documentation of IdmGetPropertiesState.

The attributes will be stored in the user session as ch.nevis.idm.Unit.<attribute>.

Attributes may be used in sub-sequent authentication steps or included in application access tokens.

For instance, use them in a Generic Authentication Step via the expression ${sess:ch.nevis.idm.Unit.<attribute>}.

Unit Properties

Enter unit properties to fetch from nevisIDM and store in the unit session.

Properties must be created in the nevisIDM via SQL.

Remember Input

Select enabled to add a Remember Input checkbox.

By ticking the checkbox the whatever has been entered by the user will be stored in a long-living cookie (named like this pattern).

Using this cookie, the login ID will be prefilled on subsequent authentications.

If no GUI is shown (e.g. to look up the user based on Login ID Source) you must select disabled.

User Not Found Error

When no user is found error code 1 is set.

If you flow shows another GUI after taking the On User Not Found exit, an error text may be displayed.

The default translation for English is: Please check your input.

In some flows (e.g. self-registration) this is not desired. Thus, you can select disabled here to remove the error code.

Use Default Profile

Should in the Authentication flow assume default profile is selected if the user has multiple profiles, or should it display a selection dialog for the user.

nevisIDM User Update

Update a user in nevisIDM.

The pattern is experimental and may be improved in future releases. We are looking forward to your feedback and requirements.

nevisIDM

Assign a nevisIDM Instance or nevisIDM Connector.

On Success

Define how to continue after user update.

Mandatory User Attributes

Define which attributes are required and how to provide them.

Example:

clientExtId: 100
email: ${sess:email}
remarks:
mobile:

Optional User Attributes

Define which attributes are optional and how to provide them.

Example:

firstName: ${sess:given_name}
name: ${sess:family_name}
country: ${sess:country}

Allow Overwrite

If enabled, the attribute or property will be stored even when there already is a stored value.

If disabled, the stored value remains unchanged in this case.

Write Empty Values

If enabled, it is possible to clear user attributes or properties. The value will be overwritten with an empty value.

This is supported only if the corresponding attribute or property is optional.

If disabled, empty values are ignored, i.e., the stored value remains unchanged.