Table of Contents

Appsettings.json

This article describes the configuration of the appsettings.json root file.

All settings can be found by opening the appsettings.json in the %OMETA_INSTALL_ROOT%\Ometa Software Suite folder.

Warning

Escape JSON file
The appsettings.json file adheres to the JSON structure format. Any special characters in file paths and connection strings must be escaped. The most common use case for escaping characters are backslashes between folder names.

For example: you would write C:\Program Files (x86)\Ometa BVBA but in the JSON format, the backslashes must be escaped: C:\\Program Files (x86)\\Ometa BVBA.

Full Example

 {
   "BamConfig": {
     "Enabled": true,
     "Destination": "File",
     "LogDirectory": "C:\\Program Files (x86)\\Ometa BVBA\\Log",
     "PortalUrl": "",
     "MaxPropertySize": 100,
     "MinimumLogLevel": "Information",
     "ProcessOverrides": []
   },
   "LogProcessing": {
     "OperatingMode": "Fixed",
     "FileProcessing": {
       "Enabled": true,
       "IntervalTimeMinutes": 1
     },
     "Cleaning": {
       "Enabled": true,
       "CleaningTime": "23:30:00",
       "DaysToKeep": 15,
       "MaximumLogDataSizeGByte": 10.0
     }
   },

   "ConnectionStrings": {
     "OmetaFrameworkDatabase": "Data Source=sqlserver;Initial Catalog=OmetaDynamicCaseSystem;Trusted_connection=yes;TrustServerCertificate=True;",
     "OmetaBamDatabase": "Data Source=sqlserver;Initial Catalog=OmetaBAMLogging;Trusted_connection=yes;TrustServerCertificate=True;"
   },
  
   "AllowedHosts": "*",
   "AllowedOrigins": [],
   "SigningCertificate": "CN=*.yourdomain.net",
 }

Database Connection Strings

Check and update if needed the connection strings to the Ometa Framework and Ometa BAM databases:

  • OmetaFrameworkDatabase: must point to the Ometa Framework database.
  • OmetaBAMDatabase must point to the the Ometa BAM database.

SQL Server On Premise: Integrated Security

Setting the trusted_connection property to yes means that the user account will be taken:

  • IIS Application pool user for the Ometa Services
    • Ometa Generic REST Service
    • Ometa Authority Service
    • Ometa Core Service
  • Service account user for the Ometa Services
    • BCA
    • BCM
    • BCSL
    • BCJS
{
  // ...
  // Other JSON Settings
  // ...
  "ConnectionStrings": {
    "OmetaFrameworkDatabase": "Data Source=dbserver.ometa.net;database=OmetaFramework;trusted_connection=yes;TrustServerCertificate=True;",
    "OmetaBamDatabase": "Data Source=sqlserver.domain.net;database=OmetaBAMDatabase;trusted_connection=yes;TrustServerCertificate=True;"
  }
}

SQL Server On Premise: SQL Users

Note

Microsoft recommends using Integrated Security over SQL Logins. Refer to the following Microsoft article.

{
  // ...
  // Other JSON Settings
  // ...
  "ConnectionStrings": {
    "OmetaFrameworkDatabase": "Data Source=dbserver.ometa.net;database=OmetaFramework;trusted_connection=yes;Uid=myUsername;Pwd=myPassword;TrustServerCertificate=True;",
    "OmetaBamDatabase": "Data Source=sqlserver.domain.net;database=OmetaBAMDatabase;trusted_connection=yes;Uid=myUsername;Pwd=myPassword;TrustServerCertificate=True;"
  }
}

Azure SQL Database

When using Azure SQL Database services for data storage, adapt the connection strings a bit:

{
  // ...
  // Other JSON Settings
  // ...
  "ConnectionStrings": {
    "OmetaFrameworkDatabase": "Data Source='your-azure-instance-sql.database.windows.net';database=dcs database;Uid=myUsername;Pwd=myPassword;Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;",
    "OmetaBamDatabase": "Data Source='your-azure-instance-sql.database.windows.net';database=OmetaBAMDatabase;Uid=myUsername;Pwd=myPassword;Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30;"
  }
}

Replace your-azure-instance-sql.database.windows.net, sqlaccount and sqlpwd with the proper corresponding values.

If for some reason no connection can be made to the Azure SQL Database, try adding the prefix 'tcp:' and port number ',1433' like this: tcp:your-azure-instance-sql.database.windows.net,1433.

Allowed Origins

AllowedOrigins defines which external origins (scheme + host + port) are trusted to send requests to the IIS services.
Only requests originating from these configured origins will be accepted, and the service will reflect the Origin header back in the response.

This mechanism is a critical security control that prevents unauthorized websites from interacting with the service on behalf of a user.

Redirect URIs configured on clients are allowed by default and should not be added to the appsettings.json file.

{
  // ...
  // Other JSON Settings
  // ...
  "AllowedOrigins": [
    "https://tenant1.sharepoint.com",
    "https://tenant2.sharepoint.com",
    "https://*.yourcompany.com"
  ]
}
Note

Changing the allowed origins here takes effect immediately. Changes on redirect URIs can take up to one minute to reflect.

Wildcard subdomains are allowed. However, you should only use them if you can trust the complete domain.

Important

A literal wildcard entry ("*") is not allowed anymore, ignored by the framework and logged as a warning. If no valid origins are configured (including all redirect uri's of clients), CORS denies all cross-origin requests.

Why this is required

Modern browsers enforce the Same-Origin Policy, which blocks web pages from calling APIs on a different origin unless the server explicitly allows it through Cross-Origin Resource Sharing (CORS) headers.

By configuring AllowedOrigins, the service:

  • Ensures that only trusted applications can access the IIS services
  • Prevents malicious websites from abusing a user’s authenticated browser session
  • Limits the exposure of sensitive endpoints and data
  • Reduces the risk of cross-site data exfiltration

Without a properly restricted list of allowed origins, any website could attempt to issue requests from a user’s browser and receive responses if the browser is authenticated.

Why you cannot use a wildcard (*)

Using a wildcard origin (*) disables the primary security benefit of CORS. It is also blocked by browsers if the request carries credentials (e.g.: realtime keys).

If a wildcard would be allowed:

  • Any website can send requests to the service
  • A malicious site could:
    • Read sensitive API responses
    • Execute actions on behalf of an authenticated user
    • Abuse authentication cookies, bearer tokens, or integrated authentication
  • Browser-based origin isolation is effectively bypassed

This turns the service into a publicly callable endpoint from any origin, which is unacceptable for services that handle authentication, user data, or internal functionality.

Important

Wildcard origins are removed by the patcher and ignored by the framework.

Content Security Policy (CSP) Configuration

The EnableCsp setting in appsettings.json controls how the application handles Content Security Policy headers. This is a security layer that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.

{
  // ...
  // Other JSON Settings
  // ...
  "EnableCsp": true
}
Key Type Default Description
EnableCsp boolean false Determines if the CSP is strictly enforced or runs in report-only mode.

How it Works

The application middleware uses this flag to decide which HTTP header to send to the client's browser:

  • Strict Mode ("EnableCsp": true)

    The server sends the Content-Security-Policy header. The browser will block any resources (scripts, styles, frames, etc.) that do not comply with the defined policy. Use this for production environments.

  • Report-Only Mode ("EnableCsp": false or omitted)

    The server sends the Content-Security-Policy-Report-Only header. The browser will allow all resources to load but will log warnings in the developer console for any violations. This is the default behavior and is recommended for testing.

Automated Policy Features

When enabled, the framework automatically builds a policy based on your configuration:

  • Self-Referencing: By default, it allows resources from its own origin ('self').
  • Allowed Origins: The requested origin will be whitelisted if defined in the AllowedOrigins configuration across multiple directives (script-src, style-src, frame-ancestors, ...).
  • Framework Requirements:
    • 'unsafe-eval' is permitted for scripts to support dynamic function creation.
    • 'unsafe-inline' is permitted for styles to ensure compatibility with Angular components.

Recommendations

  • During Development: Keep EnableCsp set to false. Monitor the browser console for CSP violation reports to ensure all necessary external domains are added to your AllowedOrigins.
  • In Production: Set EnableCsp to true to harden the application against malicious injections.

Secure Internal Communications

To improve security on internal communications, enable the specific setting InternalTransportCertificate by provide a distinguished subject name or thumbprint of the certificate:

{
  // ...
  // Other JSON Settings
  // ...
  "InternalTransportCertificate": "CN=host.yourdomain.net"
}

The certificate to use has several conditions to get it properly working. For more information about this and more, consult the article Secure Internal Communication.