We are using Spring profiles: Doc.

Start server under defined profile (add JAVA_OPTS parameters):

-Dspring.profiles.active=production

External configuration uses Spring: Doc.

Start server with external path to configuration (add JAVA_OPTS parameters):

--spring.config.location=classpath:/default.properties,classpath:/override.properties

In the application profile (application.properties) and overloadable via ConfigurationService.

# Application stage (development, test, production (default))
idm.pub.app.stage=
# Application instance / server id - is used for scheduler etc.
idm.pub.app.instanceId=idm-primary
# Enable forest index for tree structures
idm.sec.app.forest.index.enabled=true
# 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
# global datetime format on BE. Used in notification templates, logs, etc. FE uses localization key 'core:format.datetime'.
idm.pub.app.format.datetime=dd.MM.yyyy HH:mm
# create demo data at application start
idm.sec.core.demo.data.enabled=true
# demo data was created - prevent to create demo data duplicitly
idm.sec.core.demo.data.created=false

In the application profile (application.properties)

# audit table suffix
spring.jpa.properties.org.hibernate.envers.audit_table_suffix=_a
# modified flag for all audited columns
spring.jpa.properties.org.hibernate.envers.global_with_modified_flag=true
# prevent to modify attributes created, creator etc.
spring.jpa.properties.hibernate.ejb.interceptor=eu.bcvsolutions.idm.core.model.repository.listener.AuditableInterceptor
 
#
# DB ddl auto generation by hibernate is disabled - flyway database migration is used
spring.jpa.generate-ddl=true
spring.jpa.hibernate.ddl-auto=update
#
# DATASOURCE (DataSourceAutoConfiguration & DataSourceProperties)
spring.datasource.url=jdbc:postgresql://localhost:5432/bcv_idm_storage
spring.datasource.username=*****
spring.datasource.password=*****
spring.datasource.driver-class-name=org.postgresql.Driver

# String boot properties for Activiti workflow engine
# https://github.com/Activiti/Activiti/blob/master/modules/activiti-spring-boot/spring-boot-starters/activiti-spring-boot-starter-basic/src/main/java/org/activiti/spring/boot/ActivitiProperties.java
# let activiti to manage their schema
spring.activiti.databaseSchemaUpdate=true
# disable automatic jpa entities persisting - dto usage is prefered
spring.activiti.jpaEnabled=false
# Automatic process deployment
spring.activiti.checkProcessDefinitions=true
# path to automatically deployed definitions - should be the same in all modules
spring.activiti.processDefinitionLocationPrefix=classpath*:eu/bcvsolutions/idm/workflow/
# definitions name pattern - subfolders can be used
spring.activiti.processDefinitionLocationSuffixes=**/**.bpmn20.xml

In the application profile (application.properties) and overloadable via ConfigurationService.

# 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
# - expiration in millis
idm.sec.security.jwt.expirationTimeout=36000000
# - secret jwt password
idm.sec.security.jwt.secret.token=idmSecret
# - extend JWT token expiration period on each successful request
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
idm.sec.security.recaptcha.secretKey=xxx

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.

In the application profile (application.properties)

# Enable flyway migrations. 
# @see https://proj.bcvsolutions.eu/ngidm/doku.php?id=navrh:databazove_scripty
flyway.enabled=false

Module configuration (flyway-core.properties)

## 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.
# Be careful when enabling this as it removes the safety net that ensures Flyway does not migrate the wrong database in case of a configuration mistake!
flyway.core.baselineOnMigrate=true
#
# The name of Flyway's metadata table (default **schema_version**).
# By default (single-schema mode) the metadata table is placed in the default schema for the connection provided by the datasource.
flyway.core.table=idm_schema_version_core
#
# 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}

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).

# mapping pom.xml properties by default
# add custom properties if needed
#
# module version
module.<module>.build.version=@project.version@
# TODO: build number
# module.<module>.build.number=@buildNumber@
# module.<module>.build.timestamp=@timestamp@
# module vendor
module.<module>.build.vendor=@project.organization.name@
module.<module>.build.vendorUrl=@project.organization.url@
module.<module>.build.vendorEmail=info@bcvsolutions.eu
# module description
module.<module>.build.name=@project.name@
module.<module>.build.description=@project.description@

In the application profile (application.properties)

## Swagger config
# enable swagger endpoint (can be disabled for development etc.)
springfox.documentation.swagger.enabled=true
# endpoint with exposed documentations. Documentations are exposed by module e.g. <server>/api/doc?group=core
springfox.documentation.swagger.v2.path=/api/doc
#
# for static documentation generation puprose => internal usage mainly in test stage. Swagger specification on then rest endpoint is exported to given file e.g. <module>/target/swagger/swagger.json. Properties with @ are automatically filled from pom.xml properties.
# output directory and filename for swagger export - other build parts are dependent on this.
springfox.documentation.swagger.outputDir=@swagger.output.dir@
springfox.documentation.swagger.outputFilename=@swagger.output.filename@

In the application profile (application.properties) - overloadable via ConfigurationService.

idm.sec.core.emailer.test.enabled=false # enable test mode - in this mode, emails are not send
idm.sec.core.emailer.protocol=smtps # http://camel.apache.org/mail.html
idm.sec.core.emailer.host=smtp.gmail.com
idm.sec.core.emailer.port=465
idm.sec.core.emailer.username=servis.bcvsolutions@gmail.com
idm.sec.core.emailer.password=SuperHesloBCV
idm.sec.core.emailer.from=idm@bcvsolutions.eu # The FROM email address.

In the application profile (application.properties) - overloadable via ConfigurationService.

idm.pub.core.notification.template.folder=classpath*:/templates/ # classpath for loading templates
idm.pub.core.notification.template.fileSuffix=**/**.xml # template suffix

In the application profile (application.properties).

# Enable scheduler
scheduler.enabled=true
# How many times will be trigger cron tasks (ms)
scheduler.task.queue.process=3600000
# Application settings for QUARTZ (for current mvn profile)
scheduler.properties.location=/quartz-dev.properties

In the application profile (application.properties) - overloadable via ConfigurationService.

# supports delete identity
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
idm.pub.core.identity.passwordChange=ALL_ONLY
#
# required old password for change password
idm.pub.core.identity.passwordChange.requireOldPassword=true
#
# create default identity's contract, when identity is created
idm.pub.core.identity.create.defaultContract.enabled=true

In the application profile (application.properties) - overloadable via ConfigurationService.

# Default user role will be added automatically, after an identity is logged in
# could contains default authorities and authority policies configuration
# for adding autocomplete or all record read permission etc.
idm.sec.core.role.default=userRole
# Admin user role
idm.sec.core.role.admin=superAdminRole

In the application profile (application.properties) - overloadable via ConfigurationService. Every processor could have his own configuration properties under prefix:

# disable / enable event procesor
idm.sec.<module>.processor.<name>.enabled=true

Where <module> is processor's module a <name> is processor's name (see overridable processor's methods). Filled configuration properties will be shown on proccessor's content.

Common configuration properties for all processors:

• enabled - on / off
• order - comming soon

Exists proccessors configuration: implemented proccessors.

## Global property that allow disable or enable sending notification from WF
idm.sec.core.wf.notification.send=false

In the application profile (application.properties) - overloadable via ConfigurationService. Every filter could have his own configuration properties under prefix:

# filter implementation
idm.sec.<module>.filter.<entity>.<name>.impl=<beanName>

Where:

• <module> is filter's module
• <entity> is entity class simple name - filter will be applied to this domain type
• <name> is filter's name - see implemented filters

Common configuration properties for all filters:

• 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: implemented filters.

UUID of system, against which to user will be authenticated.

# ID system against which to authenticate
idm.sec.security.auth.systemId=

If you want to use redeploy and backup for example in agenda (notification template), you must define default backup folder see:

# configuration property for default backup 
idm.sec.core.backups.default.folder.path=/tmp/backup

For outgoing http communication, you can set a proxy (currently used only by ReCaptcha).

Server restart is needed to apply this configuration change.

# Proxy for HTTP requests
idm.sec.core.http.proxy=12.34.56.78:1234