Use Cases
HomeIntegrityControlManagement CenterSolutions
  • Get Started
  • Integrity | Access
    • Auth. methods
      • LDAP (Username/Password)
      • LDAP (Username/Password) + OTP (SMTP)
      • LDAP (Username/Password) + OTP (SMS)
      • Swedish BankID
      • Microsoft Entra ID (SAMLSPBroker)
      • Certificate-Based Authentication
      • Foregin eID (SAMLSPBroker)
    • Auth. methods (SAML)
      • One-Time Password (OATH)
      • Inera IdP (SITHS) (SAMLSPBroker)
      • ID-porten (Norway) (SAML IdP with OIDC RP)
      • Multiple SAML IdP's configured
        • Multiple JSON files
    • Auth. methods (OIDC)
      • Static values (OIDC) - Test only
      • Swedish BankID (OIDC)
      • UID/PWD (OIDC)
    • Auth. methods (MISC)
      • Selector filtering
      • AuthZ control
      • External links and Cancel location
    • Add a Federation or SAML SP
  • Integrity | Portal
    • Portal
  • Integrity | Enrollment
    • Software token (OATH)
    • Best practice configuration
  • Integrity | Radius
    • UID/OATH token
    • UID/Password/OATH token
    • UID/Password/SMTP
  • Integrity | API
    • Swedish Siths eID
    • Oath Token
    • OIDC M2M Authentication & Token Service
  • Control | Applications
    • Password Reset
    • Password Reset for Entra ID
    • Password Reset for Google Workspace
  • OPERATION
    • Rolling upgrade - cluster
  • TROUBLESHOOTING
    • Wrong relaystate
  • Misc
    • Address configuration externally
    • ADFS
      • Protect Fortified ID apps
      • Install and configure Fortified ID ADFS adapter for Siths eID
      • Install and configure Fortified ID ADFS adapter for Oath
    • AWS
      • Protect AWS Cognito with eID MFA
      • Protect AWS IAM Identity Center with eID MFA
    • Customization
      • Overlay - WEB
      • Overlay - Portal
      • Overlay - Password Reset
      • Overlay - Enrollment
      • Logout page
    • Dependency-Track - protect with eID MFA and SSO
    • Digitala Nationella Prov (DNP) / Skolfederation
      • Active Directory Federation Services (ADFS) with BankID as step-up-method
      • Active Directory / LDAP with BankID as step-up-method
      • Entra ID (Azure AD) with BankID as step-up-method
      • Google with BankID as step-up-method
      • Generate eduPersonPrincipalName (eppn) and store in Google
      • Generate eduPersonPrincipalName (eppn) and store in Entra ID
      • Common configuration
    • Encrypt configuration secrets
    • Microsoft Entra
      • Protect Entra ID (Azure AD) with eID MFA
      • Entra External - Support for eID (SAML)
      • Entra External - Support for eID (OIDC)
    • Expressions
    • Google
      • Common configuration for Google Workspace - Directory API
      • Common configuration for Google Workspace - authentication for Fortified ID products
      • Delegated administration for Google Workspace - teacher updates student guardians
      • Delegated administration for Google Workspace - teacher updates student password
      • Protect Google Workspace with eID MFA
    • HTTPS
    • Protect sensitive data, such as social security numbers, through obfuscation
    • Reverse proxy
      • Install Apache Web Server on Windows
      • Add SSL certificate and enable https
      • Add a Fortified ID virtual host
      • mTLS in Apache HTTPD using a Self-Signed CA and Client Certificates
    • Set AuthnContextClassRef
    • Wiki.js - OpenID Connect (OIDC)
    • Add roles based on memberOf
Powered by GitBook
On this page
  • Scenario
  • Prerequisite
  • Configure Globals and Includes
  • config.json not using either global or include
  • config.json using global
  • config.json using global and include
  • Example of a larger extracted globals.json file
  1. Misc

Address configuration externally

Use Globals and Includes to address configuration externally

PreviousWrong relaystateNextADFS

Last updated 1 year ago

Scenario

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.

Prerequisite

  • Basic knowledge about configuration of the product and the file structure.

  • The Fortified ID product of your choice installed to test with.

Configure Globals and Includes

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.

config.json not using either global or include

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.

"modules": [
 {
  "name": "LdapClient",
  "config": {
    "connection": {
      "host": "127.0.0.1",
      "port": 636,
      "bind_dn": "CN=admin,CN=Users,DC=company,DC=local",
      "bind_password": "Secret_Password",

config.json using global

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!

"globals": {
  "ldap": {
     "host": "127.0.0.1",
     "port": 636,
     "bind_dn": "CN=admin,CN=Users,DC=company,DC=local",
     "bind_password": "Secret_Password",
   }
}, 
"modules": [
 {
  "name": "LdapClient",
  "config": {
    "connection": {
      "host": "${globals.ldap.host}",
      "port": "${globals.ldap.port}",
      "bind_dn": "${globals.ldap.bind_dn}",
      "bind_password": "${globals.ldap.bind_password}"

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:

${globals.host}
${globals.ldap.host}
${globals.ldap.ldap1.host}
${globals.ldap.ldap2.host}

config.json using global and include

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.

"globals": "@include:globals.json"
, 
"modules": [
 {
  "name": "LdapClient",
  "config": {
    "connection": {
      "host": "${globals.ldap.host}",
      "port": "${globals.ldap.port}",
      "bind_dn": "${globals.ldap.bind_dn}",
      "bind_password": "${globals.ldap.bind_password}"

Below is the content of the globals.json file

{
  "ldap": {
     "host": "127.0.0.1",
     "port": 636,
     "bind_dn": "CN=admin,CN=Users,DC=company,DC=local",
     "bind_password": "Secret_Password",
   }
}

Example of a larger extracted globals.json file

{
 "file_paths": {
   "base_dir": "../customer",
   "saml_sp_file_path": "/config/resources/saml_sp_files",
   "idp_metadata_template_file_path": "/config/resources/idp_metadata_template_file"
 },
 "http": {
   "http_port": 8080
 },
 "ldap": {
   "base_dn": "dc=company,dc=local",
   "host": "127.0.0.1",
   "port": 636,
   "bind_dn": "CN=admin,CN=Users,DC=company,DC=local",
   "bind_password": "secret_password"
 },
 "keystore": {
   "alias": "fortifiedid",
   "key_password": "fortifiedid",
   "password": "secret_password",
   "path": "/config/resources/certificates/fortifiedid.p12"
 }
}

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",