Skip to content

Fortified IDDocs

Configuration

Configuration file structure and key concepts for FortifiedID EID Server.

EID Server reads its configuration from a JSON file at startup. The file passed to the -c Node argument is the entry point. All other configuration files are included from there.

The top-level config.json declares the server object and the modules array. Both are typically populated via file inclusion rather than written inline:

{
"server": {
"http": {
"enabled": true,
"listeners": "@include:http_listeners/"
}
},
"modules": "@include:modules/*.json"
}

The @include: directive replaces its value with the content of one or more JSON files at load time. This allows configuration to be split across multiple files without changing how the server reads it.

Including a directory produces an array — one element per .json file found:

"modules": "@include:modules/*.json"

Including a single file returns its content directly:

"property": "@include:other/file.json"

HTTP listeners define the network interfaces EID Server binds to. Each listener is a separate file in config/http_listeners/.

A typical production layout uses two listeners — one for the public API and one for the admin API:

{
"name": "default_8080",
"host": "0.0.0.0",
"port": 8080
}

Listener names are referenced by modules. The Eid module, for example, takes http_listener: "default_8080" in its web configuration block. Module configuration that references a listener name that does not exist will fail at startup.

The admin listener is optional. Omit admin_9090.json and the corresponding admin block in the Eid module config if the admin API is not needed.

Each module is a .json file in config/modules/. The server reads all files from this directory via the @include:modules/*.json expression in config.json and deploys each module in the order they are loaded.

A minimal module file contains a name and an optional config block:

{
"name": "HttpClient",
"config": {
"name": "default",
"idle_timeout_ms": 15000,
"connect_timeout_ms": 15000,
"request_timeout_ms": 15000
}
}

See Eid for the full configuration reference for the main EID module.

Expansion expressions replace a value with the content of another property in the same logical configuration, or with a system property or environment variable.

The syntax is ${path.to.property}:

{
"globals": {
"db": {
"jdbc_url": "jdbc:mysql://localhost:3306/fortifiedid"
}
},
"modules": [
{
"name": "Eid",
"config": {
"jdbc": {
"url": "${globals.db.jdbc_url}"
}
}
}
]
}

Available scopes in addition to the configuration itself:

Scope Description
globals Named top-level object for shared values (see below)
system Java system properties
env Process environment variables

To inject a value from the environment:

"password": "${env.EID_DB_PASSWORD}"

Globals are a top-level object in the configuration used to centralize values that are referenced from multiple places. Define them in config.json or in a separate file included into it:

{
"globals": {
"public_hostname": "eid.example.com",
"db": {
"jdbc_url": "jdbc:mysql://db.internal:3306/fortifiedid"
}
}
}

Reference a global value from any module configuration using property expansion:

"public_host": "${globals.public_hostname}"

A common pattern is to keep environment-specific values (hostnames, database URLs, keystore paths) in a globals file and keep module config files identical across environments.