Skip to main content
Version: 8.2411.x.x RR

Client policy

Client policies can be understood as client-specific configurations. Only one client policy per client is allowed.

NameData typeDefaultDescription
address.ech0010.
enabled
booleanfalseThis parameter controls the availability of the optional user address extension according to eCH-0010. If set to "true", the attributes of the optional user address extension are available on the Web GUI. If set to "false", the attributes of the optional user address extension are not visible on the Web GUI. Up to WebService version 1.37 eCH-0010 address extensions will be present in the SOAP response depending on this parameter. From WebService version 1.38 they will be included into SOAP responses by default. Modifying is allowed for all of the supported WebService versions.
allowed.user.
languages
String, comma-separated list surrounded by square brackets[de, en, fr, it] Use the language code iw for Hebrew, in for Indonesian, and ji for Yiddish.A comma-separated list of ISO-639-1 language codes. With this parameter set, the allowed languages of the given client’s users can be defined. If this parameter is set, user creation, user modification on the GUI and over SOAP, and user import on the GUI can only be executed successfully, if the given user’s language was part of the specified languages. The language of existing users won’t be adjusted automatically but the user is forced to choose an allowed language upon modification of a user.
Notes and requirements: The parameter is optional, the default value will be used if the parameter is not set. However, if it is set, it must contain at least one valid ISO-639-1 language code.
Examples:
  • allowed.user.languages=[de, en, fr, it] -> OK
  • allowed.user.languages='' -> Not OK (its value cannot be empty)
  • allowed.user.languages =[] -> Not OK (its value cannot be empty)
  • allowed.user.languages =[de] -> OK
  • allowed.user.languages =[rt] -> Not OK (invalid language code)
authentication.
loginWithEmail.
enabled
booleanfalseThis parameter determines whether users of the referred client are allowed to log in with their e-mails or not. It replaces the global parameter in nevisidm-prod.properties file with the same name, which is deprecated now. When the property is true, all user e-mails have to be unique within their clients (the unique_email property on the user). Data consistency is being checked for every client on container startup and during runtime. If this property is not set, then these fallback rules apply: first we check for an explicit value in nevisidm-prod.properties file, else apply the default.
available
CredentialTypes
int, comma-separated list surrounded by square bracketsnoneA comma-separated list of credential type IDs (for possible values see below) surrounded by square brackets, no spaces allowed. Only credentials of the enumerated types can be created in the client. The available credential types can be defined in the unit policy as well. In this case, all credential types defined in the unit policies have to be defined in the client policy as well. The "availableCredentialTypes" parameter has to contain all credential type IDs which are defined in the unit policies.
Possible values:
  • 1: Password
  • 2: Certificate
  • 3: SecurID
  • 4: Ticket
  • 5: Safeword
  • 6: OTP
  • 8: Temporary strong password
  • 9: Generic credential
  • 10: Kerberos
  • 11: mTAN
  • 12: Vasco Digipass token
  • 13: PUK
  • 14: URL ticket
  • 15: Device password
  • 16: Mobile signature
  • 17: SAML federation
  • 18: Security question
  • 19: Context password
  • 20: OATH
  • 21: FIDO UAF
  • 22: Recovery code
  • 23: FIDO 2
Examples:
  • availableCredentialTypes=[1,2] : only passwords and certificates available
  • availableCredentialTypes=[] : no credential types available
  • availableCredentialTypes= : all credential types available
  • availableCredentialTypes not defined: all credential types available
create.user.
country.default.id
int-1 (not set)Sets the default id of the country drop-down menu on the user create page.
create.user.
language.default.id
int-1 (not set)Sets the default ID of the language drop-down menu in the New user view. If the value is not set or invalid (e.g., not defined in the policy parameter allowed.user.languages), then the system sets the language in the drop-down menu based on the request locale, if possible. Otherwise, the language of the drop-down menu is based on the nevisIDM default language.
create.user.loginid.
uniquenesscheck.
casesensitive
booleanfalseWhen creating a user, uniqueness of the loginID is checked. If this parameter is true, this check is done case-sensitive. If this parameter is false, this check is done case-insensitive. Setting this parameter to true might improve performance in certain databases. If you enable this parameter you have to guarantee case-insensitive uniqueness of loginIDs by other means. Else you risk inconsistent loginIDs. This parameter has no effect on the constraint that loginIDs must be unique, ignoring case. If this parameter is true, the attempted creation of a user with a loginID that differs only in case from an already existing loginID will result in an Exception. E.g., when attempting to insert a user with loginID UserLoginId when USERLoginId already exists.
data.classificationsListnullThis parameter allows configuring classification levels for supported entities. For details, see the chapter "Information classification with the REST API".
deactivateWeak
CredentialsOn
StrongLogin
booleanfalseIf this parameter is true, the user's weak credentials will be disabled if the user logs in with a strong credential. The list of weak and strong credential types can be defined by setting the weakCredentialTypes and strongCredentialTypes parameters.
facing.cssstringcss/facing.cssSpecifies the path to the core stylesheet for this client. The path is cached in the user’s session (which requires at least a logout on change) and relative to the directory defined with the parameter web.gui.facing.location in the configuration file nevisidm-prod.properties (see the chapter "nevisidm-prod.properties"). Note: Do not try to specify different directory structures for different brandings - simply have different versions of facing.css in the same directories e.g. specify "css/facing-brand1.css" or "css/facing-brandX.css".
gui.create.application.
extid.setmanually
booleanfalseAllows you to manually set the extId of created applications. If false, the extId is autogenerated.
gui.create.credential.
extid.setmanually
booleanfalseAllows you to manually set the extId of created credentials. If false, the extId is autogenerated.
gui.create.enterpriserole.
extid.setmanually
booleanfalseAllows you to manually set the extId of created enterprise roles. If false, the extId is autogenerated.
gui.create.policyconfig.
extid.setmanually
booleanfalseAllows you to manually set the extId of created policy configurations. If false, the extId is autogenerated.
gui.create.profile.
extid.setmanually
booleanfalseAllows you to manually set the extId of created profiles. If false, the extId is autogenerated.
gui.create.template.
extid.setmanually
booleanfalseAllows you to manually set the extId of created templates. If false, the extId is autogenerated.
gui.create.unit.
extid.setmanually
booleanfalseAllows you to manually set the extId of created units. If false, the extId is autogenerated.
gui.create.user.
extid.setmanually
booleanfalseAllows you to manually set the extId of created users. If false, the extId is autogenerated.
gui.create.role.
extid.setmanually
booleanfalseThis parameter allows manual setting of the extId of the created role. If set to false, nevisIDM autogenerates the extId. If in this case the associated applications belong to multiple clients, nevisIDM takes the client policy of the first client (that is, the client whose name comes first alphabetically). Therefore, we recommend enabling this parameter for all affected clients.
gui.deputy.enabledbooleanfalseThis parameter controls the visibility of the subuser infrastructure in the GUI (see the chapter "Subuser concept").
gui.help.link.enstringnoneThis parameter sets the link for the Help button in the header of the nevisIDM GUI, if the selected display language is English. If the parameter is not set, the Help button is hidden.
gui.help.link.destringnoneThis parameter sets the link for the Help button in the header of the nevisIDM GUI, if the selected display language is German. If the parameter is not set, the Help button is hidden.
gui.help.link.itstringnoneThis parameter sets the link for the Help button in the header of the nevisIDM GUI, if the selected display language is Italian. If the parameter is not set, the Help button is hidden.
gui.help.link.frstringnoneThis parameter sets the link for the Help button in the header of the nevisIDM GUI, if the selected display language is French. If the parameter is not set, the Help button is hidden.
gui.mandatoryEnum
Properties.initiallyNotSet
booleanfalseThis parameter determines the initially preselected value for mandatory enum properties. If the parameter is true, the preselected value will be <not set>, instead of the first available value.
gui.profileAdmin.
multiRoleUnassign.enabled
booleantrueEnable/disable multiple role unassignments. If the parameter is true, the Unassign roles view is accessible from the profile administration view. This view allows unassigning multiple non-nevisIDM roles from a profile in one step.
gui.profilesearch.
profilestate.default
stringnoneThis parameter specifies the state that will be used as default in the status dropdown list of the profile search mask. It can be set to active, disabled, archived. If it is not set (or set to an invalid value), "all" will be used as default.
gui.redirect.enabledbooleantrueIf the user has no session anymore or it has expired, nevisIDM will redirect the user to the entrance page. This behavior can be disabled by setting gui.redirect.enabled=false in the client policy. In that case, the user will not be redirected. This is especially helpful for direct links into nevisIDM.
gui.selfadmin.email.
change.allowed
booleantrueEnable/disable the e-mail change in selfAdmin GUI.
gui.selfadmin.email.
change.doubleInput
booleanfalseThis parameter, when set to true, creates an additional e-mail confirmation field if gui.selfadmin.email.change.allowed is also true. The two e-mail fields should receive the same input value. Can be combined with gui.selfadmin.email.change.verify.
gui.selfadmin.email.
change.verify
booleanfalseThis parameter switches a verification process on, when gui.selfadmin.email.change.allowed is also true. The user receives an e-mail with a one-time verification code to the new e-mail address. The user should then type this code in the verification input field. Only a successful verification makes the changes persistent. Can be combined with gui.selfadmin.email.change.doubleInput. The communication event is then "Selfadmin ticket notification". Define e-mail templates for this event to use the verification procedure. This can also be combined with gui.selfadmin.mobile.change.verify, but it is not allowed to change e-mail and mobile in one stroke. Change e-mail and mobile in a two-step-process. The verify code is technically implemented with a ticket credential that will be created with the Default Ticket Policy. The ticket policy parameter ticketReuseEnable is ignored here, the ticket can be used only once.
gui.selfadmin.mobile.
change.allowed
booleantrueEnable/disable the mobile change in selfAdmin GUI.
gui.selfadmin.mobile.
change.doubleInput
booleanfalseWith this parameter set to true, the selfadmin GUI holds an additional mobile confirmation field. Precondition is that gui.selfadmin.mobile.change.allowed is also true. The user must enter the same value in both mobile fields, else a corresponding error message will be displayed. Can be combined with gui.selfadmin.mobile.change.verify.
gui.selfadmin.mobile.
change.maxTrials
int3Configures the maximum number of subsequent unsuccessful mobile change trials in combination with enabled SMS verification. This feature prevents a malicious or unintentional SMS flood to some user’s mobile device. All the successful and unsuccessful trials are audited.
gui.selfadmin.mobile.
change.ticketPolicyExtId
string-The verify code is technically implemented with a ticket credential. These special purpose tickets refer to the policy which you define via this parameter. The provided ticket policy must define the following parameters:
SMS_SMTP.smtp.host
SMS_SMTP.smtp.port
SMS_SMTP.message.from
SMS_SMTP.message.to
SMS_SMTP.message.subject.
The ticket policy parameter ticketReuseEnabled is ignored here, the ticket can be used only once.
gui.selfadmin.mobile.
change.verify
booleanfalseThis parameter switches a verification process on. Precondition is that gui.selfadmin.mobile.change.allowed is also true. The user receives an SMS message with a one-time verification code to the new mobile phone number. The user should then type this code in the verification input field. Only a successful confirmation makes the changes persistent. Can be combined with gui.selfadmin.mobile.change.doubleInput. The corresponding communication event is "Selfadmin mobile notification".
Define SMS templates for this event to use the verification procedure. (Appendix B - Template Examples) This can be combined also with gui.selfadmin.email.change.verify, but it is not allowed to change e-mail and mobile in one stroke. Change e-mail and mobile in a two-step-process.
gui.unitTree.
unauthorizedParents.
visible
booleantrueThis controls the visibility of parent units in the unit tree explorer. If set to true, the whole path which leads from the root to a unit to which the user is authorized is visible, but the unauthorized parents are not selectable. If set to false, the first authorized unit in the tree becomes root, so that only authorized nodes are visible.
gui.usersearch.
defaultMode
stringsimpleThis parameter controls the default search mode for the Search user view, for each Client entity. The default search mode is "simple". For the expanded search mode, set the attribute to "advanced".
gui.usersearch.
userstate.default
stringnoneThis parameter specifies the state that will be used as default in the status dropdown list of the user search mask. It can be set to active, disabled, archived. If it is not set (or set to an invalid value), "all" will be used as default.
loginIdGenerator.
enabled
loginIdGenerator.
minValue
loginIdGenerator.
maxValue
loginIdGenerator.
prefix
--Settings of the login ID generator. The generator is disabled by default.
The following settings are available:
  • enabled (data type: boolean, default: false) - Enables the login ID generator
  • minValue (data type: int, default: 100000) - Specifies the minimum value of the login ID generator
  • maxValue (data type: int, default: 999999) - Specifies the maximum value of the login ID generator
  • prefix (data type: string, default: empty) - Specifies a configurable string prefix. All generated login ID's will be prefixed with this string.
If the login ID generator for a client reaches the maximum value, it will start looking for non-used login ID's starting from the minimum value. If all login ID's in the range are used, you need to increase the maximum value. You must also update the table storing the current login ID value, so that it points to the last configured maximum value.
For example, if the default client ID is "100", and the default maximum value is "999999", you need to update the table as follows: update tidma_login_id_generation set current_value=999999 where client_id=100;
search.dataroom
restrictions.enabled
booleanfalseUsers in the client will have their search result restricted according to their data room.
search.pager.modestringsimpleSets the page switcher display. Valid values are "simple" or "wide".
search.profile.
rowsperpage
int10Sets the maximum number of entries per page on the profile detail view.
search.profile.
unitabbrname.show
booleanfalseEnables the optional column "unit abbreviation name" in the result table of the profile search.
search.profile.
unitdisplayname.show
booleanfalseEnables the optional column "unit displayname" in the result table of the profile search.
search.user.
loginid.casesensitive
booleanfalseThis parameter determines if user searches by loginId are case-sensitive. Setting the parameter true requires searches to be submitted in the correct case. This has to be made sure by the customer. Consider setting the parameter true only if not using Oracle database, since Oracle case-insensitive searches perform quite well.
search.wildcard.
enabled
booleanfalseEnables the automatic wildcard search, i.e., all search values are automatically pre- and postfixed with wildcards.
strongCredentialTypesint, comma-separated list surrounded by square brackets2 - Certificate
3 – SecurID
5 – Safeword
8 - Temp. strong password
12 - Vasco Digipass token
A comma-separated list of credential type IDs (for possible values see below) surrounded by square brackets, no spaces allowed. The credential types listed in this parameter are considered as strong credentials.
Possible values:
  • 1: Password
  • 2: Certificate
  • 3: SecurID
  • 4: Ticket
  • 5: Safeword
  • 6: OTP
  • 8: Temporary strong password
  • 9: Generic credential
  • 10: Kerberos
  • 11: mTAN
  • 12: Vasco Digipass token
  • 13: PUK
  • 14: URL ticket
  • 15: Device password
  • 16: Mobile signature
  • 17: SAML federation
  • 18: Security question
  • 19: Context password
  • 20: OATH
  • 21: FIDO UAF
  • 22: Recovery code
Notes and requirements: The parameter is optional, the default value will be used if the parameter is not set. However, if it is set, it must contain at least one valid credential type. The parameters weakCredentialTypes and strongCredentialTypes cannot contain the same credential id.
Example:
  • strongCredentialTypes is not in the policy - OK (use the default values)
  • strongCredentialTypes='' - NOK (its value cannot be empty)
  • strongCredentialTypes=[] - NOK (its value cannot be empty)
  • strongCredentialTypes=[1,2,3] - OK
  • weakCredentialTypes=[1,2,3] and strongCredentialTypes=[3,5,6] - NOK (the credential type 3 is defined in both parameters)
unit.indicatorstringshortThis parameter indicates how the unit is displayed.
short: a short displayname based on unit name, localized displayname and abbreviation name is used (e.g., 11010 - unit u1a en - u1a en)
hierarchical: the localized hierarchical name ist used (e.g., unit u en >> unit u1 en >> unit u1a en)
unitSearch.
enableClassicMode
booleanfalseEnable the classic mode for unit searches in the GUI instead of the JavaScript-based unit tree.
userBulkImport.
ignoreInvalidEntries
booleanfalseThis parameter is used for the user import feature. It defines whether it is allowed to upload not only flawless excel documents. If the parameter is true, the valid rows will be imported even if the excel file contains invalid rows as well. The invalid rows will be ignored. If the parameter is false, no user will be imported if the excel file contains invalid rows.
userBulkImport.
maxEntries
int100This parameter is used for the user import feature. It defines the maximum number of users to be created by the import. The maximum value is limited to 65000.
userBulkImport.
templateMode
stringGENERATEDThis parameter is used for the user import feature. It defines whether a generic or a custom template is used for the import. Its value can be GENERATED or CUSTOM.
userBulkImport.
templatePath
stringemptyThis parameter is used for the user import feature. If custom template is used, this parameter defines the path of the template file.
userBulkImport.
templateVersion
double1.0This parameter is used for the user import feature. It defines which template version has to be used.
validation.
mobileSignature.
msisdn.unique
booleanfalseEnable/disable uniqueness check of the MSISDN of mobile signature credentials. If the parameter is true, the MSISDN of the mobile signature credentials has to be unique per client. Otherwise, no uniqueness check is applied for MSISDNs.
validation.user.
email.mandatory
booleantrueDefines whether the user’s e-mail address is mandatory or optional.
validation.user.
firstname.mandatory
booleantrueDefines whether the user’s first name is mandatory or optional.
validation.user.
mobile.mandatory
booleanfalseDefines whether the user’s mobile number is mandatory or optional.
validation.user.
mobile.unique
booleanfalseDefines whether the user's mobile phone number must be unique per client. Uniqueness is checked by string comparison. There is no semantic comparison that checks whether two mobiles are logically identical (by handling spaces, country prefix, etc.). Use validation.user.phone.regex to enforce a specific format.
validation.user.
name.mandatory
booleantrueDefines whether the user’s name is mandatory or optional.
validation.user.
sex.mandatory
booleanfalseDefines whether the user’s sex is mandatory or optional.
validation.user.
country.mandatory
booleanfalseDefines whether the user’s country is mandatory or optional.
validation.user.
phone.regex
stringnone, i.e., no validation check performedRegular expression for input validation of telephone, telefax and mobile. Example: `^(+
weakCredentialTypesint, comma-separated list surrounded by square brackets1 - Password
4 – Ticket
A comma-separated list of credential type IDs (for possible values see below) surrounded by square brackets, no spaces allowed. The credential types listed in this parameter are considered as weak credentials. If the deactivateWeakCredentialsOnStrongLogin parameter is true, the user's weak credentials will be disabled, if the user logs in with a strong credential.
Possible values:
  • 1: Password
  • 2: Certificate
  • 3: SecurID
  • 4: Ticket
  • 5: Safeword
  • 6: OTP
  • 8: Temporary strong password
  • 9: Generic credential
  • 10: Kerberos
  • 11: mTAN
  • 12: Vasco Digipass token
  • 13: PUK
  • 14: URL ticket
  • 15: Device password
  • 16: Mobile signature
  • 17: SAML federation
  • 18: Security question
  • 19: Context password
  • 20: OATH
  • 22: Recovery code
Notes and requirements: The parameter is optional, the default value will be used if the parameter is not set. However, if it is set, it must contain at least one valid credential type. The parameters weakCredentialTypes and strongCredentialTypes cannot contain the same credential id.
Example:
  • weakCredentialTypes is not in the policy -> OK (use the default values)
  • weakCredentialTypes='' -> NOK (its value cannot be empty)
  • weakCredentialTypes=[] -> NOK (its value cannot be empty)
  • weakCredentialTypes=[1,2,3] -> OK
  • weakCredentialTypes=[1,2,3] and strongCredentialTypes=[3,5,6] -> NOK (the credential type 3 is defined in both parameters)
webservice.
selfadmin.deleteCaller
String, possible values: archive, deletearchiveThis parameter determines whether the caller is deleted or archived by the deleteCaller web service. If the value of the parameter is "deleted", the caller will be deleted. If the value of the parameter is "archive", the caller will be archived.
application.feature.
othergender.enabled
BooleanfalseThis parameter enables the third possible gender option "other" for users of the client. Disabling this policy does not affect the already stored gender data of a user and its presentation. Note: The "other" gender is not supported on the user import feature.
user.email.
unicode.allowed
booleanfalseThis parameter allows having unicode characters in e-mail addresses. An e-mail address is valid if it has a valid top level domain (TLD) and exactly one @ sign. This client policy has precedence over the configuration parameter application.feature.email.validation.enabled. For more information on the parameter application.feature.email.validation.enabled, see Configuration files.

Migration hints for the "login with e-mail" feature

With the Client policy parameter authentication.loginWithEmail.enabled you can enable the "login with e-mail" feature (for a description, see the previous table). Additionally, you need the derived, technical attribute unique_email of the user table TIDMA_USER. You have to migrate user information manually. For this purpose,

  • Connect to the database with a client (for example, a MariaDB client, Oracle Instant Client or pgAdmin for PostgreSQL), and

  • Submit a statement such as you can see in the following samples:

    • Before enabling:

      1. Manually make all email addresses of users in that client unique.
      2. Execute the SQL statement to copy them to the unique_email column.
      UPDATE TIDMA_USER
      SET unique_email = email,
      ctl_mod_uid = 'migration',
      ctl_mod_dat = SYSDATE,
      ctl_tcn = ctl_tcn + 1
      WHERE email is not null;
    • Before disabling: Nothing to do.