Examples
9.1.1. Config example scenarios and usage

Consider the following example scenarios - multiple instances with very similar configuration:

Example:
Description:
Stages Test and Production
  • IAM instance in test: environment TEST
  • IAM instance in production: environment PRODUCTION
Similar instances (HA)
  • Productive IAM instance: environment PROD1
  • Failover IAM instance: environment PROD2
Tenants with similar configuration
  • Productive IAM instance for bank A: BankAProd
  • Productive IAM instance for similarly configured bank B: BankBProd
  • Productive IAM instance for similarly configured bank C: BankCProd

Use the "configuration environments" feature to:

  • Manage the configuration for all similarly configured instances centrally.
  • Reduce redundancy and configuration management complexity.
  • Assure that production configuration is really what you tested.

The feature does not change or centralize the deployment process.

Technical Information

  • The configuration for all environments is stored in one configuration XML (medusa-configuration.xml). It can be deployed to all instances without having to be modified.
  • Environment-specific values are only used for the specified environment. If a property is not defined for a specific environment, the value from the shared environment is used. In combination with inheritance and/or configuration contexts, the used value depends on the order in which the concepts are applied. The value displayed in the Config Editor is the one used by the IAM code.
  • Sensitive configuration values (such as database passwords, shared secrets, etc.) should be stored per instance using the 9.3. Storing sensitive configuration values externally feature.
  • You can export the configuration for selected environments (so you do not have to worry about bits of test configuration in your live systems) - see below.
Medusa configuration xml

Every instance defines its environment (see below), which defines the property values of the configuration to consider.