Address configuration externally
Use Globals and Includes to address configuration externally
Last updated
Use Globals and Includes to address configuration externally
Last updated
You like to use variables for easier management or externalise data from the config.json file.
Here are some example scenarios where globals and includes could work:
Let say you like to move a config.json file between different environments, for example test and production. LDAP address, certificates, database connection might be different and used in several places in the config.json file.
Here is where you could use variables so the adress of, for example, your database connection only needs to be changed in one place.
You can also extract the entire globals section to a separate file so when you move your config.json file between test and production environments it just works because test and environment have its own global JSON files.
Perhaps you have a JSON file containing sensitive data, like passwords. Then you could have that data in a separate file. So when you start a Fortified ID product the include file is only available during startup of system. When system is started the file can be removed. Note: The include file must be available whenever the system starts.
We will in this use case show how to extract the entire globals section and put it to a separate file that will be addressed from server.json.
Using include is not just fpr globals. Any configuration in the configuration file can be extracted. If you like you can extract every authenticator to a separate JSON file using include.
Basic knowledge about configuration of the product and the file structure.
The Fortified ID product of your choice installed to test with.
Note: The examples files used in this use case are not a fully functional file. It is just snippets of configuration files showing how includes and globals can be used.
Below is an example where, for example, LDAP info is addressed directly in a module. If the LDAP data where also to be found in more places then when you, for example, move this JSON-file to another environment you need to remember to update LDAP data in all places in the JSON-file.
Here we introduce globals. The name globals can really be whatever you like to call it, BUT we have UI admin tools to make configuration easier than edit raw JSON data, that type of tool will only support a name called globals, so best practice is to use the name globals!
As you can see you can have a flat globals structure or as above with levels. Only globals is mandatory as name.
Example could be:
Here we introduce include also! We have externalise the entire global section. I you have a test and production environment in place and you make changes in config.json you can now move the config.json file between the two environments without doing any updates to environment specific data.
Below is the content of the globals.json file
Example of how to address data in server.json
LDAP example
"host": "${globals.ldap.host}"
Certificate example
"alias": "${globals.keystore.alias}",
file path in SAML
"metadata_cache": "${globals.file_paths.base_dir}/cache",
