Simplified, Centralized configuration model in WSO2 IS-5.9.0 onward.

Source: https://logicalread.com/wp-content/uploads/2017/07/centralized-active-directory-managemnent-and-clean-up.png

Old configuration model

In previous versions of WSO2-IS(before 5.9.0), there are several sets of configuration files for several sets of components like ‘carbon.xml’(Carbon platform configurations), ‘identity.xml’(identify component configurations), and ‘axis2.xml’(axis2 configurations).

Challenges we faced

When a developer tries to play with the WSO2-IS, once making a set of configuration changes, the developer needs to remember all configuration changes that he made. Otherwise, he needs to go through each and every configuration file and validate the configuration changes.

The new configuration model

With the new configuration model, the developer can configure everything in one place that we called a centralized configuration model. From here onward the ‘deployment.toml’ file located in the ‘<IS_HOME>/repository/conf/’ directory, will responsible for all configuration changes.

How it works

During the startup of the server, it will override each and every configuration file (old .xml files) with the configuration changes mentioned in the ‘deployment.toml’.

Backward compatibility

This feature is also backward compatible as if some developer is confidently familiar with the old configuration model, they just need to remove the newly added ‘deployment.toml’ file and move forward with the old configuration model.

Mapping with the old model

There a mapping between the new configuration model with each and every configuration in the previous model. So we need to add the new configurations to the ‘deployment.toml’ as per this mapping. Otherwise, the server will not override the old configuration files(.xml) as per the changes pointed in the ‘deployment.toml’.

You can the mapping templates from the ‘<IS_HOME>/repository/resources/conf/templates/repository/conf’ directory. That will contain a set of files(.j2 files) with the respective directory structure.

Example scenario

In a developer’s scenario, the requirement is to disable the consent page for the SSO scenario. With the old configuration model, he needs to set the ‘EnableSSOConsentManagement’ property to false under the ‘Consent’ tag located in the ‘<IS_HOME>/repository/conf/identity/identity.xml’ file as below.

<Consent>
    <!— Specify whether consent management should be enable during SSO. -->
    <EnableSSOConsentManagement>false</EnableSSOConsentManagement>
</Consent>

Now let’s perform the same action to disable the consent page for the SSO scenario in new centralized configuration model.

Navigate to the ‘identity.xml.j2’ file located in the ‘<IS_HOME>/repository/resources/conf/templates/repository/conf/identity’ directory.

Then identify the mapped value for the ‘EnableSSOConsentManagement’ property as ‘authentication.consent.prompt’ in ‘identity.xml.j2’ file as below.

<Consent>
<! — Specify whether consent management should be enable during SSO. →
     <EnableSSOConsentManagement>{{authentication.consent.prompt}}</EnableSSOConsentManagement>
</Consent>

After that, we need to configure that in the ‘deployment.toml’ as bellow. First split the property by the last ‘.’ character. Then put the first segment in ‘[]’ and set the corresponding value for the last segment in the immediate next line.

[authentication.consent]
prompt = false

Here we are done the configuration with the centralized model. If we need to identify what was the configuration changes that we made, just need to open the ‘deployment.toml’ and it will only contain the changes that we have done.

Hope this helps to get more information about the new configuration model along with how it maps to the old configurations and how it works.

References

[1] https://is.docs.wso2.com/en/5.9.0/references/new-configuration-model/