Differences

This shows you the differences between two versions of the page.

--- devel:documentation:application_configuration:dev:backend [2020/09/08 12:09]
tomiskar [Bulk actions]
+++ devel:documentation:application_configuration:dev:backend [2022/05/02 11:24]
sourek
@@ Line 3: / Line 3: @@
 {{tag> configuration final property properties config setup}}
-The application uses a Spring boot configuration in the ''application.properties'' files. All the configuration items which are used solely for idm begin with ''idm.'' prefix. The configuration items from the file can be overloaded through a setting agenda in the gui => a server restart isn't needed for changing the configuration with ''idm.'' prefix, which was one of the main goals. The configuration is saved in the database. Use ''ConfigurationService'' for reading and saving configuration items.
+The application uses a Spring boot configuration in the ''application.properties'' files. All the configuration items which are used solely for idm begin with ''idm.'' prefix. The configuration items from the file can be overloaded through a setting agenda in the gui ⇒ a server restart isn't needed for changing the configuration with ''idm.'' prefix, which was one of the main goals. The configuration is saved in the database. Use ''ConfigurationService'' for reading and saving configuration items.
 Naming conventions of the configuration items in idm:
-  * ''idm.'' - configuration items for the needs of idm
-  * ''idm.pub.'' - public configuration items - published on a public rest endpoint (e.g. version)
+  * ''idm.''  - configuration items for the needs of idm
-  * ''idm.sec.'' - system configuration items - published on a secure rest endpoint and available for configuration by the application administrator. They are used for backend configuration. If configuration item is confidential, then value is stored in [[..:..:security:dev:confidential-storage|confidential storage]] and value is not send to frontend, application logs etc. Items with key ''password'', ''token'', ''secret'' are automatically set as confidential - use it for configuration items defined in property file only.
+  * ''idm.pub.''  - public configuration items - published on a public rest endpoint (e.g. version)
-  * ''idm.sec.<module>.'' or ''idm.pub.<module>.'' - configuration items of the given module. Use ''ModuleDescriptor#getId()'' as ''<module>''.
+  * ''idm.sec.''  - system configuration items - published on a secure rest endpoint and available for configuration by the application administrator. They are used for backend configuration. If configuration item is confidential, then value is stored in [[..:..:security:dev:confidential-storage|confidential storage]] and value is not send to frontend, application logs etc. Items with key ''password'', ''token'', ''secret''  are automatically set as confidential - use it for configuration items defined in property file only.
-  * if the name of a configuration item contains the''password'' or ''token'' chain, the value of the configuration item is hidden in the rest interface listing (or rather replaced with substitute characters).
+  * ''idm.sec.<module>.''  or ''idm.pub.<module>.''  - configuration items of the given module. Use ''ModuleDescriptor#getId()''  as ''<module>''.
-  * It is better to use constants for keys, e.g. ''ConfigurationService.IDM\_PUBLIC\_PROPERTY\_PREFIX + "core.identity.delete"'' - using seperator constant in key name suffix is not preferred - constant can be simply found by key suffix ("ctrl-f" + "core.identity.delete").
+  * if the name of a configuration item contains the''password''  or ''token''  chain, the value of the configuration item is hidden in the rest interface listing (or rather replaced with substitute characters).
+  * It is better to use constants for keys, e.g. ''ConfigurationService.IDM\_PUBLIC\_PROPERTY\_PREFIX + "core.identity.delete"''  - using seperator constant in key name suffix is not preferred - constant can be simply found by key suffix ("ctrl-f" + "core.identity.delete").
 ==== Configure environment properties ====
@@ Line 20: / Line 21: @@
 Start server under defined profile ([[https://proj.bcvsolutions.eu/ngidm/doku.php?id=help:czechidm_server_install_guide#vyber_profilu_aplikace|add JAVA_OPTS parameters]]):
 <code>
 -Dspring.profiles.active=production
 </code>
 == Configured devstack profiles ==
-  * ''default'' - the default profile - configured to db h2. If a developer downloads the project from Git, the application will run without any other configuration over h2 database with demo data (by admin user ...). Default profile is used for issuing a demo.
+  * ''default''  - the default profile - configured to db h2. If a developer downloads the project from Git, the application will run without any other configuration over h2 database with demo data (by admin user …). Default profile is used for issuing a demo.
-  * ''dev'' - developing profile configured to postgresql. In the future, we can move the configuration itself to special profiles - their combinations (e.g. test+ postgresql or dev + mysql). We will be able to cover more variants of environment versus database.
+  * ''dev''  - developing profile configured to postgresql. In the future, we can move the configuration itself to special profiles - their combinations (e.g. test+ postgresql or dev + mysql). We will be able to cover more variants of environment versus database.
-  * ''test'' - test profile - configured to db h2 and **it's used for unit and intergration testing only**. Don't use this profile for test environment - create your own profiles (testing / production).
+  * ''test''  - test profile - configured to db h2 and **it's used for unit and intergration testing only**. Don't use this profile for test environment - create your own profiles (testing / production).
-  * ''release'' - release profile - all modules in CzechIdM repository are included, they are released together under one version.
+  * ''release''  - release profile - all modules in CzechIdM repository are included, they are released together under one version.
 === External configuration ===
@@ Line 37: / Line 38: @@
 Start server with external path to configuration ([[https://proj.bcvsolutions.eu/ngidm/doku.php?id=help:czechidm_server_install_guide#vyber_profilu_aplikace|add JAVA_OPTS parameters]]):
 <code>
 --spring.config.location=classpath:/default.properties,classpath:/override.properties
 </code>
 === Environment properties ===
 [[https://proj.bcvsolutions.eu/ngidm/doku.php?id=help:czechidm_server_install_guide#vyber_profilu_aplikace|Add JAVA_OPTS parameters]]
 ===== Configuration items =====
-==== Application/ Server ===
+==== Application/ Server ====
 In the application profile (application.properties) and overloadable via ConfigurationService.
 <code properties>
@@ Line 60: / Line 59: @@
 # Public properties - available for frontend without authentication (show information about app, decorators etc.).
 #
-# Application stage - development, test, production
+# Application stage - development, test, production.
 idm.pub.app.stage=
 # Application instance / server id - is used for scheduler etc.
-# Should be defined in property file only
+# Can be defined in property file only! Overidding via ConfigurationService is not possible for application instance (~ more instanceos on the same database)
 idm.pub.app.instanceId=idm-primary
+# Frontend server url.
+# E.g. http://localhost:3000
+# Default: The first 'idm.pub.security.allowed-origins' configured value is used (~ backward compatible).
+# @since 12.0.0
+idm.pub.app.frontend.url=
+# Backend server url.
+# E.g. http://localhost:8080/idm
+# Default: Url is resolved dynamically from current servlet request.
+# @since 12.0.0
+idm.pub.app.backend.url=
 # global date format on BE. Used in notification templates, logs, etc. FE uses localization key 'core:format.date'.
 idm.pub.app.format.date=dd.MM.yyyy
@@ Line 71: / Line 81: @@
 # Show identifiers (uuid) in frontend application. Empty value by default => identifier is shown, when application 'idm.pub.app.stage' is set to 'development'.
 idm.pub.app.show.id=
-# Show transaction identifiers (uuid) in frontend application
+# Show transaction identifiers (uuid) in frontend application.
 idm.pub.app.show.transactionId=false
-# Show role environment in frontend application for roles (table, role detail, niceLabel, info components, role select)
+# Show role environment in frontend application for roles (table, role detail, niceLabel, info components, role select).
 idm.pub.app.show.environment=true
-# Show role baseCode in frontend application for roles (table, role detail, niceLabel, info components, role select)
+# Show role baseCode in frontend application for roles (table, role detail, niceLabel, info components, role select).
 idm.pub.app.show.role.baseCode=true
+# Rendered column in role table agenda. Comma is used as separator. Order of rendered columns is preserved as configured.
+# Available columns:
+# - name - role name info card with link to detail
+# - baseCode - role base code (without environment)
+# - environment - role environment
+# - disabled
+# - description
+idm.pub.app.show.role.table.columns=name, baseCode, environment, disabled, description
+# Show role catalogue item code in role catalogue tree
+idm.pub.app.show.roleCatalogue.tree.code=false
+# Number of items (pagination) in role catalogue tree in root level. Used on role select and agenda.
+idm.pub.app.show.roleCatalogue.tree.pagination.root.size=25
+# Number of items (pagination) in role catalogue tree in other levels. Used on role select and agenda.
+idm.pub.app.show.roleCatalogue.tree.pagination.node.size=25
+# Number of items (pagination) in tree node structure in root level.
+idm.pub.app.show.treeNode.tree.pagination.root.size=50
+# Number of items (pagination) in tree node structure in other levels.
+idm.pub.app.show.treeNode.tree.pagination.node.size=50
 # Available size options for tables in frontend application
 idm.pub.app.show.sizeOptions=10, 25, 50, 100
@@ Line 84: / Line 112: @@
 # Bulk action can enforce showing in quick access button (by bulk action configuration).
 idm.pub.app.show.table.quickButton.count=5
 # Quick button for bulk actions in tables will be included in drop down select box too (available as button + menu item with text).
 # Number of selected record is shown in drop down select header.
 idm.pub.app.show.table.quickButton.menuIncluded=true
-# show default form for newly created user
+# Show default form for newly created user.
-# default form can be disabled => at least one configured form projection is needed
+# Default form can be disabled => at least one configured form projection is needed.
 idm.pub.app.show.identity.formProjection.default=true
+# Rendered column in identity table agenda. Comma is used as separator. Order of rendered columns is preserved as configured.
+# Available columns:
+# - username - username with link to detail
+# - entityinfo - identity info card
+# - lastName
+# - firstName
+# - externalCode - personal number
+# - email
+# - state
+# - passwordexpiration - information about identity password epiration
+# - description
+# Note: Table in identity agenda can be configured with this property (common identity table with columns is not specified on FE).
+# If you want to configure rendered columns for all tables generalized from identity table (e.g. on role or tree node detail),
+# you can use FE configuration https://wiki.czechidm.com/devel/documentation/application_configuration/dev/frontend
+idm.pub.app.show.identity.table.columns=username, lastName, firstName, externalCode, email, state, description
+idm.pub.app.show.identityRole.table.columns=role, roleAttributes, environment, identityContract, contractPosition, validFrom, validTill, directRole, automaticRole, incompatibleRoles
 # If is true, then role-request description will be show on the detail.
 # Description will hidden if this property will be false and role request
 # doesn't contains any value in description (can be filled during the approval process).
 idm.pub.app.show.roleRequest.description=true
+# Show logout content (~ page) with message, after user is logged out.
+# @since 12.0.0
+idm.pub.app.show.logout.content=false
+#
+# Configurable application theme
+# @since 12.0.0
+idm.pub.app.show.theme={ "palette": { "type": "light", "primary":       { "main": "#5cb85c", "contrastText": "#fff" }, "secondary":       { "main": "#f50057", "dark": "#c51162", "contrastText": "#fff" }, "success":       { "main": "#4caf50", "contrastText": "#ffffff" }, "warning":       { "main": "#ff9800", "contrastText": "#fff" }, "action": {"loading": "rgba(255, 255, 255, 0.7)"}, "background":       { "default": "#fafafa", "paper": "#fff" } }, "shape": {"borderRadius": 3} }
+#
+# Configurable application logo (attachment uuid identifier)
+# Recommended logo size is 165 x 40 px.
+# @since 12.0.0
+idm.pub.app.show.logo=
+# Footer help link url.
+# @since 12.0.0
+idm.pub.app.show.footer.help.link=https://wiki.czechidm.com/start
+# Footer service desk link url.
+# @since 12.0.0
+idm.pub.app.show.footer.serviceDesk.link=https://redmine.czechidm.com/projects/czechidmng
 #
 # Private properties - used on backend only.
 #
-# create demo data at application start
+# Create demo data at application start.
 idm.sec.core.demo.data.enabled=true
-# demo data was created - prevent to create demo data duplicitly
+# Demo data was created - prevent to create demo data duplicitly.
 idm.sec.core.demo.data.created=false
 # Create init data at application start. Init data (product provided roles) are updated automatically with pruct updates.
 # Set property to false to disable init data creation and updates.
 idm.sec.core.init.data.enabled=true
 </code>
-==== Jpa ===
+=== Change server for asynchronous processing (switch application instance) ===
+@since 11.1.0
+Application instance (server) is used for asynchronus processing - for scheduled tasks, asynchronous long running tasks and events. Instance identifier can be defined in the application profile (application.properties) by property ''idm.pub.app.instanceId''. When we want to schedule and process asynchronous tasks and event on other instace (or when one instance shutdown), then we can switch processing by provided bulk action ''Change server for asynchronous processing''  in configuration agenda:
+{{  .:switch-instance-bulk-action.png  }}
+Previous and new instance identifier is required as input parameters. All scheduled tasks and all created (~ not processed) asynchronous long running tasks and events will be moved from previous to new instance and will be processed on new instance (server).
+Bulk action is available for logged user with required authorities and permissions:
+  * ''CONFIGURATION_UPDATE''  - configuration property contains instance for asynchronous processing will be changed ⇒ authority and ''UPDATE''  base permission for property ''idm.sec.core.event.asynchronous.instanceId''  is required.
+  * ''SCHEDULER_UPDATE''  - scheduled tasks and created (~ not processed) asynchronous long running tasks will be changed.
+  * ''ENTITYEVENT_UPDATE''  - created (~ not processed) asynchronous events will be changed.
+==== Jpa ====
 In the application profile (application.properties)
@@ Line 140: / Line 218: @@
 spring.datasource.testOnBorrow=true
 spring.datasource.validationQuery=SELECT 1
 # Enlarge pool size by default. This property should be revised for each project. Size should be configured by task and event thread pool size - should be higher than sum of pool sizes.
-spring.datasource.hikari.maximumPoolSize=50
+spring.datasource.maximumPoolSize=50
 </code>
+====== Additional datasources ======
+As of version 12.2.0 we are no longer using spring-boot datasource autoconfiguration. Instead, we define datasources ourseves. This decision was motivated by our need for multiple independent datasources with separated connection pools, which was previously not possible.
+Notable changes:
+  *
+There are by default two datasources configured
+      * datasource - default datasource, which is being used for almost all database communication (Flyway, JPA repositories)
+      * loggingDatasource - This datasource is used by our database logging appender to write logging messages, when databes appender is enabled. The reason why this is done by separate datasource is to prevent database logging to hog database connections and hinder the application performance
+  *
+Configuration properties, that have changed with introduction of additional datasources:
+      * //''spring.datasource.''url →// //''spring.datasource.jdbcUrl'' //
+      * spring.datasource.hikari.* → spring.datasource.*
+  *
+Both datasources are required for the app to start.
+      * By default, both datasources are configured for H2 in-memory database
+      * If you specify property spring.datasource.jdbcUrl, IdM will no longer use in memory database for main datasource and instead it will configure connection using spring.datasource.* properties
+      * The same goes for loggingDatasource, which is configured using spring.logging-datasource.* properties
+===== Datasource configuration properties
+CzechIdM uses HikariCP to manage connections. All possible configuration properties for each datasource can be seen as fields in [[https://github.com/openbouquet/HikariCP/blob/master/src/main/java/com/zaxxer/hikari/HikariConfig.java|https://github.com/openbouquet/HikariCP/blob/master/src/main/java/com/zaxxer/hikari/HikariConfig.java]] class.
+===== Developer =====
+      * If you are using ''EntityManager''  in your code, you will run into the issue with autowiring. In order to fix it, you need to explicitly specify, which ''EntityManager''  bean you want spring to autowire. You can use
+        * @CoreEntityManager` annotation, if you want to autowire main application datasource (in most cases you want to use this
+        * @Qualifier("coreEntityManager") annotation, if you want to autowire main application datasource and do not want to explicitly define dependency on core-api module
 === JNDI datasource ===
 Firstly is needed to configure JNDI resource in the J2EE server. Here is a configuration snippet for Tomcat. It assumes PostgreSQL as the database:
 <code xml>
 <Context antiJARLocking="true" path="/idm">
-	<Resource
+    <Resource
-	    name="PostgresDS"
+        name="PostgresDS"
-	    auth="Container"
+        auth="Container"
-	    type="javax.sql.DataSource"
+        type="javax.sql.DataSource"
-	    username="*****"
+        username="*****"
-	    password="*****"
+        password="*****"
-	    driverClassName="org.postgresql.Driver"
+        driverClassName="org.postgresql.Driver"
-	    url="jdbc:postgresql://localhost:5432/bcv_idm_storage"
+        url="jdbc:postgresql://localhost:5432/bcv_idm_storage"
-	    maxActive="8"
+        maxActive="8"
             maxIdle="4"/>
 </Context>
 </code>
 In the application profile (application.properties), update datasource properties:
 <code properties>
 # JNDI location of the datasource. Class, url, username & password are ignored when set.
 spring.datasource.jndi-name=PostgresDS
 </code>
-In **logback-spring.xml** configuration (by profile, if db appender is used), update datasource properties:
+In **logback-spring.xml**  configuration (by profile, if db appender is used), update datasource properties:
 <code xml>
 ...
 <springProperty name="spring.datasource.jndi-name" source="spring.datasource.jndi-name"/>
-<appender name="DB" class="ch.qos.logback.classic.db.DBAppender">
+<appender name="DB" class="eu.bcvsolutions.idm.core.exception.IdmDbAppender">
-	<connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
+    <connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
-		<!-- please note the "java:comp/env/" prefix -->
+        <!-- please note the "java:comp/env/" prefix -->
-		<jndiLocation>java:comp/env/${spring.datasource.jndi-name}</jndiLocation>
+        <jndiLocation>java:comp/env/${spring.datasource.jndi-name}</jndiLocation>
-	</connectionSource>
+    </connectionSource>
 </appender>
 ...
 </code>
 === Using SSL ===
-  - Configure PostgreSQL server, documentation: https://jdbc.postgresql.org/documentation/head/ssl.html#ssl-server
+  - Configure PostgreSQL server, documentation: [[https://jdbc.postgresql.org/documentation/head/ssl.html#ssl-server|https://jdbc.postgresql.org/documentation/head/ssl.html#ssl-server]]
-  - Short example: https://www.howtoforge.com/postgresql-ssl-certificates
+  - Short example: [[https://www.howtoforge.com/postgresql-ssl-certificates|https://www.howtoforge.com/postgresql-ssl-certificates]]
-  - Create new truststore specifically for the CzechIdM. When starting your Java application you must specify this keystore and password to use ''-Djavax.net.ssl.trustStore=path/to/mystore -Djavax.net.ssl.trustStorePassword=mypassword''. For testing purposes, it is possible to set truststore password to ''changeit'' which is the Java default - you then have to specify only path to the truststore.
+  - Create new truststore specifically for the CzechIdM. When starting your Java application you must specify this keystore and password to use ''-Djavax.net.ssl.trustStore=path/to/mystore -Djavax.net.ssl.trustStorePassword=mypassword''. For testing purposes, it is possible to set truststore password to ''changeit''  which is the Java default - you then have to specify only path to the truststore.
-<note important>It is technically possible to import certificate into the (systemwide) Java ''cacerts'' truststore, but this poses significant risk.
+<note important>It is technically possible to import certificate into the (systemwide) Java ''cacerts''  truststore, but this poses significant risk.
 While updating custom java deployment:
-  * Not being a "visible" part of IdM deployment, one can easily omit migrating certificates into the new Java ''cacerts'' truststore. In this case, IdM will not be able to connect anywhere where the SSL connection is used.
+  * Not being a "visible" part of IdM deployment, one can easily omit migrating certificates into the new Java ''cacerts''  truststore. In this case, IdM will not be able to connect anywhere where the SSL connection is used.
 While updating Java OS packages:
-  * Nowadays, most Linux distros offering packages with OpenJDK, OracleJDK, ... use "extracted" truststore, which is basically ''cacerts'' truststore located somewhere under ''/etc/ssl/...'' and available to every Java distribution on the system. This truststore is constructed by an utility ''update-ca-trust'' from a list of CA certificates located elsewhere on the filesystem. When updating packages with JDK, ca-certs and such, the ''update-ca-trust'' can be invoked, effectively rewriting the extracted truststore. In this case, any changes made only to the truststore will be lost.
+  * Nowadays, most Linux distros offering packages with OpenJDK, OracleJDK, … use "extracted" truststore, which is basically ''cacerts''  truststore located somewhere under ''/etc/ssl/…''  and available to every Java distribution on the system. This truststore is constructed by an utility ''update-ca-trust''  from a list of CA certificates located elsewhere on the filesystem. When updating packages with JDK, ca-certs and such, the ''update-ca-trust''  can be invoked, effectively rewriting the extracted truststore. In this case, any changes made only to the truststore will be lost.
 </note>
@@ Line 201: / Line 323: @@
 Update datasource properties:
 <code properties>
 # add ssl usage flag, see https://jdbc.postgresql.org/documentation/head/connect.html
 spring.datasource.url=jdbc:postgresql://localhost:5432/bcv_idm_storage?ssl=true
 </code>
@@ Line 211: / Line 335: @@
 In the application profile (application.properties):
 <code properties>
@@ Line 225: / Line 347: @@
 # Size in MB
 idm.sec.cache.terracota.resource.pool.size=32
 </code>
 ==== Attachment storage ====
-''DefaultAttachmentManager'' stores binary files on file system. Binary files can be attached to any entity, which implements ''AttachableEntity'' interface, [[..:..:modules_rpt:dev:attachment_manager| read more]].
+''DefaultAttachmentManager''  stores binary files on file system. Binary files can be attached to any entity, which implements ''AttachableEntity''  interface, [[..:..:modules_rpt:dev:attachment_manager|read more]].
 In the application profile (application.properties):
@@ Line 239: / Line 361: @@
 spring.servlet.multipart.max-file-size=100MB
 spring.servlet.multipart.max-request-size=100MB
 </code>
@@ Line 261: / Line 384: @@
 # Temporary file is used mainly for upload files internaly. When upload is complete, then temporary file is moved into normal IdM attachment (~ temporary file is not reachable, after user session ends).
 idm.sec.core.attachment.tempTtl=1209600000
 </code>
 ==== Activiti workflow ====
 <code properties>
 # String boot properties for Activiti workflow engine
@@ Line 280: / Line 405: @@
 # definitions name pattern - subfolders can be used
 spring.activiti.processDefinitionLocationSuffixes=**/**.bpmn20.xml
 </code>
@@ Line 288: / Line 414: @@
 <code properties>
 # allowed origins for FE
-# the first value is used as frontend url to notification templates
 idm.pub.security.allowed-origins=http://localhost:3000,http://localhost
 # auth token
@@ Line 298: / Line 423: @@
 idm.sec.security.jwt.token.extend.expiration=true
 # recaptcha
 # - recaptchaservice endpoint
 idm.sec.security.recaptcha.url=https://www.google.com/recaptcha/api/siteverify
 # - secret key, can be generated here https://www.google.com/recaptcha/admin (generate V2 checkbox)
 # - test secret key: https://developers.google.com/recaptcha/docs/faq#id-like-to-run-automated-tests-with-recaptcha-v2-what-should-i-do
 idm.sec.security.recaptcha.secretKey=xxx
-</code>
-Allowed-origins defines, which resources can use backend API methods. e.g. When there is a web server serving as reverse proxy on the same server as BE, the http://localhost:3000 may be the right value.
+</code>
+Allowed-origins defines, which resources can use backend API methods. e.g. When there is a web server serving as reverse proxy on the same server as BE, the [[http://localhost:3000|http://localhost:3000]] may be the right value.
 ==== Flyway ====
@@ Line 313: / Line 438: @@
 <code properties>
 # Enable flyway migrations.
 # @see https://proj.bcvsolutions.eu/ngidm/doku.php?id=navrh:databazove_scripty
 flyway.enabled=false
 </code>
@@ Line 323: / Line 449: @@
 ## Core Flyway configuration
 #
 # Whether to automatically call baseline when migrate is executed against a non-empty schema with no metadata table.
 # This schema will then be baselined with the baselineVersion before executing the migrations.
 # Only migrations above baselineVersion will then be applied.
 # This is useful for initial Flyway production deployments on projects with an existing DB.
@@ Line 336: / Line 462: @@
 # Comma-separated list of locations to scan recursively for migrations. The location type is determined by its prefix.
 # Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain both sql and java-based migrations.
 # Locations starting with filesystem: point to a directory on the filesystem and may only contain sql migrations.
 # IdmFlywayMigrationStrategy resolves used jdbc database dynamically - ${dbName} in location could be used.
 flyway.core.locations=classpath:eu/bcvsolutions/idm/core/sql/${dbName}
 </code>
 ==== Module configuration ====
-Information about module can be defined in property file (module-<module>.properties - e.g. module-core.properties). This property file is loaded by ''PropertyModuleDescriptor''. Module properties are not editable through ''ConfigurationService'' (''idm.pub.'' prefix is not used).
+Information about module can be defined in property file (module-<module>.properties - e.g. module-core.properties). This property file is loaded by ''PropertyModuleDescriptor''. Module properties are not editable through ''ConfigurationService''  (''idm.pub.''  prefix is not used).
 <code properties>
@@ Line 361: / Line 488: @@
 module.<module>.build.name=@project.name@
 module.<module>.build.description=@project.description@
 </code>
@@ Line 366: / Line 494: @@
 In the application profile (application.properties)
 <code properties>
 ## Swagger config
@@ Line 377: / Line 506: @@
 springfox.documentation.swagger.outputDir=@swagger.output.dir@
 springfox.documentation.swagger.outputFilename=@swagger.output.filename@
 </code>
@@ Line 394: / Line 524: @@
 # The FROM email address.
 idm.sec.core.emailer.from=idm@bcvsolutions.eu
 </code>
@@ Line 407: / Line 538: @@
 idm.sec.core.notification.template.folder=classpath*:/eu/bcvsolutions/idm/template/
 idm.sec.core.notification.template.fileSuffix=**/**.xml # template suffix
 </code>
@@ Line 420: / Line 552: @@
 idm.sec.core.script.folder=classpath*:/eu/bcvsolutions/idm/scripts/
 idm.sec.core.script.fileSuffix=**/**.xml
-</code>
+</code>
 ==== Scheduler ====
@@ Line 436: / Line 568: @@
 # Task executor core pool size. Uses CPU count as default.
 scheduler.task.executor.corePoolSize=
 # Task executor max pool size. Uses CPU corePoolSize * 2 as default.
 # maxPoolSize has to be higher than corePoolSize (IllegalArgumentException is thrown otherwise).
 # When queueCapacity is full, then new threads are created from corePoolSize to maxPoolSize.
@@ Line 445: / Line 577: @@
 # Thread priority for threads in event executor pool - 5 by default (normal).
 scheduler.task.executor.threadPriority=
-# Event queue processing period (ms). Period to read prepared (~created) asynchronous entity events from queue.
+# Asynchronous task processing is stopped.
+# Asynchronous task processing is stopped, when instance for processing is switched => prevent to process asynchronous task in the meantime.
+# Asynchronous task processing can be stopped for testing or debugging purposes.
+# Asynchronous task are still created in queue, but they are not processed automatically - task can be executed manually from ui.
+idm.sec.core.scheduler.task.asynchronous.stopProcessing=false
+# Event queue processing period (ms). Period to read prepared (~created) asynchronous entity events from queue.
 # Events are processed in batch configured by property 'idm.sec.core.event.asynchronous.batchSize'. If you events are processed quickly (~provisioning on your environment is quick), then batch size can be higher or this property can be lower.
 # Default 500ms.
@@ Line 451: / Line 588: @@
 # Event executor core pool size. Uses CPU count + 1 as default.
 scheduler.event.executor.corePoolSize=
 # Event executor max pool size. Uses CPU corePoolSize * 2 as default.
 # maxPoolSize has to be higher than corePoolSize (IllegalArgumentException is thrown otherwise).
 # When queueCapacity is full, then new threads are created from corePoolSize to maxPoolSize.
@@ Line 460: / Line 597: @@
 # Thread priority for threads in event executor pool - 6 by default (a little higher priority than normal 5).
 scheduler.event.executor.threadPriority=6
 </code>
@@ Line 467: / Line 605: @@
 <code properties>
 # supports delete identity. Needed on FE (=> public) to render available bulk action in table
 # @deprecated @since 10.6.0 - action can be disabled by bulk action configurable api - use 'idm.sec.core.bulk-action.identity-delete-bulk-action.enabled=false'.
 idm.pub.core.identity.delete=true
 #
 # default password change type for custom users, one of values:
 # DISABLED - password change is disable
 # ALL_ONLY - users can change passwords only for all accounts
 # CUSTOM - users can choose for which accounts change password
 # Needed on FE (=> public)
 idm.pub.core.identity.passwordChange=CUSTOM
 #
 # required old password for change password.
 # Needed on FE (=> public)
 idm.pub.core.identity.passwordChange.requireOldPassword=true
 #
@@ Line 485: / Line 623: @@
 # true - change to IdM and all system
 # false - change to all system except IdM
 # Needed on FE (=> public)
 idm.pub.core.identity.passwordChange.public.idm.enabled=true
-#
-# create default identity's contract, when identity is created.
-# skipped in synchronizations - contract synchronization should be provided.
-idm.pub.core.identity.create.defaultContract.enabled=true
 #
 # Skip identity dashboard content - show full detail directly (link from table or from info component)
 # Needed on FE (=> public)
 idm.pub.core.identity.dashboard.skip=
+#
+# Create default identity's contract, when identity is created.
+# Skipped in synchronizations - contract synchronization should be provided.
+idm.sec.core.identity.create.defaultContract.enabled=true
+# Creates default identity's contract with configured position name.
+idm.sec.core.identity.create.defaultContract.position=Default
+# Creates default identity's contract with configured state. Valid contract will be crated by default, other possible values:
+# EXCLUDED - Excluded from evidence - remains valid, but roles assigned for this contract are not added for logged identity.
+# DISABLED - Invalid by user - not changed by dates.
+idm.sec.core.identity.create.defaultContract.state=
+# Number of days related to current date - will be used for set contract valid till date (current date + expiration in days = valid till).
+# Contact valid till will not be set by default (~ contract expiration is not configured by default).
+idm.sec.core.identity.create.defaultContract.expiration=
+#
+# Profile image max file size in readable string format (e.g. 200KB).
+idm.sec.core.identity.profile.image.max-file-size=512KB
 </code>
@@ Line 505: / Line 656: @@
 # The protected interval can be set using the property idm.sec.core.contract-slice.protection-interval, where the value is the number of days.
 # If the number of days between the termination of the contract and its renewal in the following time slice is less than or equal to the number
 # of days set in the protection interval, then the date of the contract validity from the following slice will be used instead of the date of
 # termination of the contract from the currently valid slice.
 idm.sec.core.contract-slice.protection-interval=0
 </code>
 ==== Role ====
@@ Line 553: / Line 703: @@
 # Look out: when separator is changed, then all roles should be updated (manually from ui, by scripted LRT or by change script).
 idm.sec.core.role.codeEnvironmentSeperator=|
 </code>
 ==== Tree ====
 Tree structures configuration properties.
@@ Line 565: / Line 717: @@
 # Default tree node (uuid) - is used, when default contract is created. More in Contractual relationship doc.
 idm.sec.core.tree.defaultNode=
 </code>
 Internal properties used for tree indexing (forest index) - holds index state:
 <code properties>
 # forest index is valid. Is set to false, when index exception occurs and tree index has to be rebuild
 idm.sec.core.treeType.<tree-code>.valid=true
 # rebuild index in progress (true). When tree type index rebuild is in progress, then tree node cannot be created / updated / deleted.
 idm.sec.core.treeType.<tree-code>.rebuild=false
 </code>
@@ Line 582: / Line 737: @@
 # disable / enable asynchronous event processing. Events will be executed synchronously, if it's disabled. Enabled by default.
 idm.sec.core.event.asynchronous.enabled=true
+# Asynchronous event processing is stopped.
+# Event processing is stopped, when instance for processing is switched => prevent to process instances in the meantime.
+# Asynchronous event processing can be disabled for testing or debugging purposes.
+# Events are still created in queue, but they are not processed.
+idm.sec.core.event.asynchronous.stopProcessing=false
 # Asynchronous events will be executed on server instance with id. Default is the same as {@link ConfigurationService#getInstanceId()} (current server instance).
 idm.sec.core.event.asynchronous.instanceId=
@@ Line 587: / Line 747: @@
 # If you events are processed quickly (~provisioning on your environment is quick), then batch size can be higher (in combination with higher 'scheduler.event.queue.process' property).
 idm.sec.core.event.asynchronous.batchSize=15
 </code>
 === Entity event processors ===
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
-Every processor could have his own configuration properties under prefix:
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Every processor could have his own configuration properties under prefix:
 <code properties>
 # disable / enable event procesor
@@ Line 597: / Line 759: @@
 # override event types for given processor
 idm.sec.<module>.processor.<name>.eventTypes=CREATE,UPDATE
 </code>
-Where ''<module>'' is processor's module and ''<name>'' is processor's name (see overridable processor's methods). Filled configuration properties will be shown on [[..:..:architecture:dev:events#implemented_processors|processor's content]].
+Where ''<module>''  is processor's module and ''<name>''  is processor's name (see overridable processor's methods). Filled configuration properties will be shown on [[..:..:architecture:dev:events#implemented_processors|processor's content]].
 Common configuration properties for all processors:
-  * ''enabled'' - on / off
-  * ''eventTypes'' - list of event types (separated by comma) to which given processor reacts
-  * ''order'' - comming soon
+  * ''enabled''  - on / off
+  * ''eventTypes''  - list of event types (separated by comma) to which given processor reacts
+  * ''order''  - comming soon
 Exists processors configuration: [[..:..:architecture:dev:events#implemented_processors|implemented proccessors]].
 ==== Bulk actions ====
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
+@since 10.6.0
-Every bulk action could have his own configuration properties under prefix:
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Every bulk action could have his own configuration properties under prefix:
 <code properties>
 # disable / enable bulk action
 idm.sec.<module>.bulk-action.<name>.enabled=true
 </code>
-Where ''<module>'' is bulk action module and ''<name>'' is bulk action name.
-Common configuration properties for all bulk actions:
+Where ''<module>''  is bulk action module and ''<name>''  is bulk action name.
-  * ''enabled'' - true / false
-  * ''order'' - bulk action order (for FE only)
-  * ''icon'' - Icon on frontend (for FE only). Icon libraries can be used: ''component:'', ''fa:'', ''glyph:''.
-  * ''level'' - bulk action level ~ button and icon color (for FE only). Available options: ''success'', ''info'', ''warning'', ''error''.
-  * ''deleteAction'' - true / false - Action deletes records (for FE only). Action will be in bottom menu section, is action is included in menu.
-  * ''quickButton'' - true / false - Render action as quick button (for FE only). The first available actions are rendered as buttons, if icon is defined. This configuration enforces rendering action as quick button (order is ignored).
+Common configuration properties for all bulk actions:
+  * ''enabled''  - **true**  / false.
+  * ''order''  - bulk action order (for FE only). Action provided default order in implementation.
+  * ''icon''  - Icon on frontend (for FE only). Icon libraries can be used: ''component:'', ''fa:'', ''glyph:''. Icon is loaded from FE locale by default.
+  * ''level''  - bulk action level ~ button and icon color (for FE only). Available options: ''success''  (default value), ''info'', ''warning'', ''error''.
+  * ''deleteAction''  - true / **false**  - Action deletes records (for FE only). Action will be in bottom menu section, is action is included in menu.
+  * ''quickButton''  - true / **false**  - Render action as quick button (for FE only). The first available actions are rendered as buttons, if icon is defined. This configuration enforces rendering action as quick button (order is ignored).
+  * ''quickButtonable''  - **true**  / false - Action can be included in quick buttons on FE. Set to **false**, when button should be not rendered ⇒ action will be rendendered in drop down menu only.
+==== Workflow settings for approval of change user roles ====
-==== Workflow settings for approval of change user roles =====
 <code properties>
 ## WF
@@ Line 656: / Line 824: @@
 # Default main WF for approve all roles.
 idm.sec.core.processor.role-request-approval-processor.wf=approve-identity-change-permissions
 </code>
-==== Notification from Workflow =====
+==== Universal requests ====
+<code properties>
+## Universal requests
+# Role
+idm.pub.core.request.idm-role.enabled=false
+# Defines type of guarantee. Requests will be approving only by guarantee with this type.
+# If returns null, then all guarantees will be used for approving (no limitations).
+idm.sec.core.request.idm-role.approval.guarantee-type=
+</code>
+==== Notification from Workflow ====
 <code properties>
 ## Global property that allow disable or enable sending notification from WF
@@ Line 666: / Line 848: @@
 ## Enable sending notification of changing roles to user, who made request
 idm.sec.core.wf.notification.implementer.enabled=true
 </code>
 ==== Confidential storage ====
-Properties **is not** overloadable via ''ConfigurationService''. For more info [[..:..:security:dev:confidential-storage|see]]
+Properties **is not**  overloadable via ''ConfigurationService''. For more info [[..:..:security:dev:confidential-storage|see]]
 <code properties>
@@ Line 679: / Line 862: @@
 # or secretKey defined in the external file - secret.keyPath
 # cipher.crypt.secret.keyPath=/path/to/key
 </code>
 ==== Entity filters ====
 In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
 <code properties>
-# Enable / disable check filter is properly registered, when filter is used (by entity and property name). Throw exeption, when unrecognised filter is used.
+# Enable / disable check filter is properly registered, when filter is used (by entity and property name).
+# Throws exception, when unrecognized filter is used.
 idm.sec.core.filter.check.supported.enabled=true
+# Check count of values exceeded given maximum.
+# Related to database count of query parameters (e.g. Oracle = {@code 1000}, MSSql = {@code 2100}).
+# Throws exception, when size is exceeded. Set to {@code -1} to disable this check.
+idm.sec.core.filter.check.size.maximum=500
 </code>
 Every registered filter could have his own configuration properties under prefix:
 <code properties>
 # enable / disable filter - enabled by default. When filter is disabled and property is filled in filter, then ''disjunction'' criteria is added => no data will be returned
@@ Line 695: / Line 887: @@
 # filter implementation
 idm.sec.<module>.filter.<entity>.<name>.impl=<beanName>
 </code>
 Where:
-  * ''<module>'' is filter's module - overriden module has to be used (e.g. default filter is in core module, then ''core'' module identifier has to be used)
-  * ''<entity>'' is entity class simple name - filter will be applied to this domain type (e.g. ''IdmIdentity'')
-  * ''<name>'' the name of the property name during which the filter is actively evaluated, if it is stated in the filtering criteria (=> ''get'' parameter)
-  * ''<beanName>'' is filter's bean name - see [[..:..:architecture:dev:filters#implemented_filters|implemented filters]]
+  * ''<module>''  is filter's module - overriden module has to be used (e.g. default filter is in core module, then ''core''  module identifier has to be used)
+  * ''<entity>''  is entity class simple name - filter will be applied to this domain type (e.g. ''IdmIdentity'')
+  * ''<name>''  the name of the property name during which the filter is actively evaluated, if it is stated in the filtering criteria (⇒ ''get''  parameter)
+  * ''<beanName>''  is filter's bean name - see [[..:..:architecture:dev:filters#implemented_filters|implemented filters]]
 Common configuration properties for all filters:
-  * ''enabled'' - on / off
-  * ''impl'' - contains implementation (Spring bean name) of given filter. When property of given ''<name>'' will be set for filter, then this implementation will be used for filtering. New module could register new filter for defined entity and name - by this configuration one of provided implementation will be selected and used.
+  * ''enabled''  - on / off
+  * ''impl''  - contains implementation (Spring bean name) of given filter. When property of given ''<name>''  will be set for filter, then this implementation will be used for filtering. New module could register new filter for defined entity and name - by this configuration one of provided implementation will be selected and used.
 Exists filters configuration: [[..:..:architecture:dev:filters#implemented_filters|implemented filters]].
 ==== Notification senders ====
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
-Senders could have his own configuration properties under prefix:
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Senders could have his own configuration properties under prefix:
 <code properties>
 # sender implementation
 idm.sec.<module>.notification-sender.<notificationType>.impl=<beanName>
 </code>
 Where:
-  * ''<module>'' is senders's module - overriden module has to be used (e.g. default sender is in core module, then ''core'' module identifier has to be used)
-  * ''<notificationType>'' is notification type, which has to be supported by configured sender by ''<<beanName>>''
+  * ''<module>''  is senders's module - overriden module has to be used (e.g. default sender is in core module, then ''core''  module identifier has to be used)
+  * ''<notificationType>''  is notification type, which has to be supported by configured sender by ''<<beanName>>''
 Common configuration properties for all senders:
-  * ''impl'' - contains implementation (Spring bean name) of given sender. This sender implementation will be used for sending notifications with ''<notificationType>''. New module could register new sender implementation for notification types (even new notification type can be created) - by this configuration one of provided implementation will be selected and used.
+  * ''impl''  - contains implementation (Spring bean name) of given sender. This sender implementation will be used for sending notifications with ''<notificationType>''. New module could register new sender implementation for notification types (even new notification type can be created) - by this configuration one of provided implementation will be selected and used.
 Read more about [[..:..:notifications:dev:notification_manager|notification manager]].
 ==== Authentication ====
 UUID of system, against which to user will be authenticated. This authentication is from version 10.4.0 deprecated.
 <code properties>
 # ID system against which to authenticate
 idm.sec.security.auth.system=
 </code>
 Authentication against multiple system wich to user will be authenticated (since 10.4.0) - ID or Code can be used:
 <code properties>
 idm.sec.acc.security.auth.order1.system=
 idm.sec.acc.security.auth.order2.system=
 </code>
 Maximum system for authentication can be set with the property:
 <code properties>
 idm.sec.acc.security.auth.maximumSystemCount=50
 </code>
-More about authenticator can be found [[devel:documentation:security:dev:authentication|there]].
+More about authenticator can be found [[..:..:security:dev:authentication|there]].
 === Authentication filters ===
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
-Authentication filter could have his own configuration properties under prefix:
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Authentication filter could have his own configuration properties under prefix:
 <code properties>
 # enable/ disable filter - enabled by default or by filter implementation.
 idm.sec.<module>.authentication-filter.<name>.enabled=true
 </code>
 Where:
-  * ''<module>'' is filter's module - overriden module has to be used (e.g. default filter is in core module, then ''core'' module identifier has to be used)
-  * ''<name>'' is filter's name - see overridable filter's ''#getName()'' method. Filter name could be the same as bean name in context.
+  * ''<module>''  is filter's module - overriden module has to be used (e.g. default filter is in core module, then ''core''  module identifier has to be used)
+  * ''<name>''  is filter's name - see overridable filter's ''#getName()''  method. Filter name could be the same as bean name in context.
 Common configuration properties for all filters:
-  * ''enabled'' - on / off
+  * ''enabled''  - on / off
 === SSO authentication filter ===
 [[..:..:security:dev:security#sso|Single-Sign-On mechanism]] can be configured with following properties:
 <code properties>
 # Allow SSO authentication
@@ Line 770: / Line 978: @@
 # The uids that can't be authenticated by SSO
 idm.sec.core.authentication-filter.core-sso-authentication-filter.forbidden-uids=
 </code>
 === Remote user authentication filter ===
 Login into IdM by preset request remote user by servlet container can be configured with following properties:
 <code properties>
 # Allow remote user authentication
@@ Line 781: / Line 992: @@
 # The uids that can't be authenticated by SSO
 idm.sec.core.authentication-filter.core-remote-user-authentication-filter.forbidden-uids=
 </code>
-This authentication filter reuses SSO authentication filter behavior above (''uid-suffixes'', ''forbidden-uids''), but application administrator can be logged by this filter (identity with ''APP_ADMIN'' authority).
+This authentication filter reuses SSO authentication filter behavior above (''uid-suffixes'', ''forbidden-uids''), but application administrator can be logged by this filter (identity with ''APP_ADMIN''  authority).
+=== Two-factor authentication ===
+[[..:..:security:dev:security#two-factor_authentication|Two-factor authentication]] can be configured in the application profile (application.properties) with following properties:
+<code properties>
+# Verification secret length
+totp.secret.length=32
+# Time Period ~ period to generate new authentication code
+totp.time.period=30
+# Time Discrepancy - number of past (but still valid) authentication codes (e.g. when code is sent by notification, then user could need more time to fill it into CzechIdM)
+totp.time.discrepancy=1
+</code>
+=== CAS authentication filter ===
+@since 12.0.0 [[..:..:security:dev:security#cas_authentication|CAS authentication]] can be configured with following properties:
+<code properties>
+# Enable authentication via CAS. If enabled, "idm.sec.core.cas.url" become mandatory and must be set for SSO authentication via CAS to work. Default: false
+idm.pub.core.cas.enabled=false
+# Other properties
+# Base URL where CAS is accessible. Syntax of this field is https://hostname-of-CAS/URI.
+idm.sec.core.cas.url=
+# IdM service name configured as service on CAS server.
+# When service is configured, then login and logout redirect urls, should be defined directly in CAS service configuration.
+# Default: service name for login / logout is created dynamically by BE server url (recommended).
+idm.sec.core.cas.service=
+# Suffix which is, in effect, appended to idm.sec.core.cas.url. Resulting URL is used for login operation in CAS. It must start with slash (eg. /login).
+idm.sec.core.cas.login-path=/login
+# Suffix which is appended to idm.sec.core.cas.url. Resulting URL is used for single sign-out operation. It must start with slash (eg. /logout).
+idm.sec.core.cas.logout-path=/logout
+# Ticket can be given as request parameter (recommended, configured by default).
+idm.sec.core.cas.parameter-name=ticket
+# Header name in which CAS sends the ticket value. Ticket can be given as request header. Not configured by default.
+idm.sec.core.cas.header-name=
+# Path to CzechIdM for the HTTP Referer header used by CAS while redirecting back to application. This value is concatenated with CAS ticket to form Referer header. Syntax of this field is https://hostname-of-CzechIdM/URI/?ticket=. Not configured by default.
+idm.sec.core.cas.header-prefix=
+</code>
 ==== Backup ====
-If you want to use redeploy and backup for example in agenda (notification templates, scripts), you must define default backup folder.
-When redploy is used, then actual templates (or scripsts) are loaded from classpath by configuration (for templates or scripts) and deployed into application. Previous templates (or scripts) are backup too.
+If you want to use redeploy and backup for example in agenda (notification templates, scripts), you must define default backup folder. When redploy is used, then actual templates (or scripsts) are loaded from classpath by configuration (for templates or scripts) and deployed into application. Previous templates (or scripts) are backup too.
 <code properties>
-# configuration property for default backup
+# Configuration property for backup files.
+# Configured attachment storage patrh ( see 'idm.sec.core.attachment.storagePath') is used as default.
 idm.sec.core.backups.default.folder.path=/tmp/backup
 </code>
 ==== Http proxy ====
-For outgoing http communication, you can set a proxy (currently used only by ReCaptcha).
-**Server restart** is needed to apply this configuration change.
+For outgoing http communication, you can set a proxy (currently used only by ReCaptcha).
+**Server restart**  is needed to apply this configuration change.
 <code properties>
 # Proxy for HTTP requests
 idm.sec.core.http.proxy=12.34.56.78:1234
 </code>
@@ Line 811: / Line 1069: @@
 # use cglib for proxies by default
 spring.aop.proxy-target-class=true
 </code>
 ==== Virtual system ====
-VS configurations allows define implementers via assigned IdM role or directly by selected identities. If you do not define none directly implementers and none role in VS configuration, then will be used implementers from default role.
-Default role can be defined in configuration:
+VS configurations allows define implementers via assigned IdM role or directly by selected identities. If you do not define none directly implementers and none role in VS configuration, then will be used implementers from default role. Default role can be defined in configuration:
 <code properties>
 # If you do not define default role, then will be used **superAdminRole** as default!
 idm.sec.vs.role.default=<some-code-of-role>
 </code>
@@ Line 827: / Line 1087: @@
 # Long polling
 idm.pub.app.long-polling.enabled=true
 </code>
@@ Line 840: / Line 1101: @@
 # It's possible to automatic mapped existed account on the target system. It means, before create new account (call create on the connector),
 # we try to found account (by generated UID) on the target system. If account will be
 # returned, then will be mapped on the IdM account. Target account will be reused and only updated by connector.
 # - true: for reusing account
@@ Line 849: / Line 1110: @@
 # Default provisioning timeout in milis - every longer provisioning operations will ends with timeout exception (prevent to stuck running operations).
 # 3 minutes by default.
-# Timeout has to be configured >= 1000, otherwise default will be returned.
+# Timeout has to be configured>= 1000, otherwise default will be returned.
 idm.sec.acc.provisioning.timeout=180000
 </code>
 ==== Provisioning global break ====
-<note tip>For enable global provisioning break you must set configurations properties defined below, otherwise global provisioning break will not be active.</note>
+<note tip>For enable global provisioning break you must set configurations properties defined below, otherwise global provisioning break will not be activated.</note>
 <code properties>
@@ Line 910: / Line 1173: @@
 # Global break for delete. Recipient will be solved as identities that has assigned defined role/s (role code or id, split by ',')
 idm.sec.acc.provisioning.break.delete.roleRecipients
 </code>
@@ Line 916: / Line 1180: @@
 === Report executor ===
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Every report executor (~report) could have his own configuration properties under prefix:
-Every report executor (~report) could have his own configuration properties under prefix:
 <code properties>
 # disable / enable report
 idm.sec.<module>.report-executor.<name>.enabled=true
 </code>
-Where ''<module>'' is report's module a ''<name>'' is report's name.
+Where ''<module>''  is report's module a ''<name>''  is report's name.
 Common configuration properties for all reports:
-  * ''enabled'' - on / off
+  * ''enabled''  - on / off
 === Report renderer ===
-In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''. Every report renderer could have his own configuration properties under prefix:
-Every report renderer could have his own configuration properties under prefix:
 <code properties>
 # disable / enable renderer
 idm.sec.<module>.report-renderer.<name>.enabled=true
 </code>
-Where ''<module>'' is renderer's module a ''<name>'' is renderer's name.
+Where ''<module>''  is renderer's module a ''<name>''  is renderer's name.
 Common configuration properties for all renderers:
-  * ''enabled'' - on / off
+  * ''enabled''  - on / off
 ==== Logger ====
@@ Line 947: / Line 1215: @@
 # Show thread name configured by thread pools (task, event) in logs (generated name is shown otherwise)
 # Two appenders 'console' and 'file' are provided by product. Same configuration is needed for your custom appenders (added in logback.xml).
-logging.pattern.console=%d{yyyy-MM-dd HH:mm:ss.SSS} %5level %relative --- [%thread] %logger{36}.%M : %msg%n
+logging.pattern.console=%d{yyyy-MM-dd HH:mm:ss.SSS} %5level %relative --- [%thread] %logger{60}.%M : %msg%n
-logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss.SSS} %5level %relative --- [%thread] %logger{36}.%M : %msg%n
+logging.pattern.file=%d{yyyy-MM-dd HH:mm:ss.SSS} %5level %relative --- [%thread] %logger{60}.%M : %msg%n
 </code>
-Logger levels can be configured programmatically (override ''logback.xml'' file with default logger levels configuration).
+Logger levels can be configured programmatically (override ''logback.xml''  file with default logger levels configuration).
 In the application profile (''application.properties'') - overloadable via ''ConfigurationService'':
@@ Line 957: / Line 1226: @@
 <code properties>
 idm.sec.core.logger.<packageName>=<level>
 </code>
-Where ''<packageName>'' is package name to set logger ''<level>''.
+Where ''<packageName>''  is package name to set logger ''<level>''.
 Example:
 <code properties>
 idm.sec.core.logger.eu.bcvsolutions=DEBUG
 </code>
+==== Monitoring ====
+=== Monitoring evaluator ===
+In the application profile (''application.properties'') - overloadable via ''ConfigurationService''.
+<code properties>
+# disable / enable monitoring evaluator
+idm.sec.<module>.monitoring-evaluator.<name>.enabled=true
+</code>
+Where ''<module>''  is monitoring's module a ''<name>''  is monitoring's name.
+Common configuration properties for all monitorings:
+  * ''enabled''  - true / false