How to enable or disable Audit logging

The auditing process implemented in Kodjin FHIR Server is in accordance with Audit event resource definition and IHE profile for Basic Audit Log Patterns. For further implementation note, please refer to Audit Logging page.

To enable auditing, navigate to the Global event configuration at etc/kodjin/<environment>/globals.yaml.gotmpl To configure auditing, navigate to the Audit event configuration at etc/kodjin/<environment>/values/fhir-config/audit_log.json

By default auditing is switched off.

AuditEvent section in Global file. To enable auditing set AUDIT_LOG_ENABLED: true. If enabled is set to true, every request will be audited based on the filter_mode option in Audit event configuration file.

  # Audit log environment variables
  auditLog:
    # Enable audit log
    AUDIT_LOG_ENABLED: false

The rule to include or exclude specific interactions and resources from audit events is defined by specifying criteria within the audit configuration. This configuration determines which events are recorded and which are omitted, allowing for tailored auditing based on specific interactions (such as read, write, delete) and resources (such as Patient, Observation). By configuring these rules, organizations can ensure that their auditing focuses on significant events, thereby optimizing performance and compliance with regulatory requirements.

Options:

filter_mode: exclude or include - defines the rule for including or excluding specific interactions and resources from audit events (see parameters below). When set to exclude, everything will be audited except for the exclusions. Conversely, when set to include, everything will be omitted from auditing except for the inclusions defined in the interaction.
interaction: is an array of possible actions: read, vread, update, patch, delete, history, create, search from set of action, there is an array of FHIR resources. Wildcards are supported, meaning All actions or All resources

Example of the audit_log.json file

Enabled (exclude from auditing)Enabled (include in auditing)

In this file, auditing is enabled with filter_mode set to exclude. This means that all interactions will be audited, except those defined in the interactions section. Read interactions for StructureDefinition will be excluded from the audit. Additionally, updates to any resource (PUT) will also be excluded, as well as any actions involving these resources: ValueSet, CodeSystem, ConceptMap, and SearchParameter.

  {
    "buffer_size": 8,
    "filter_mode": "exclude",
    "interactions": {
      "read": ["StructureDefinition"],
      "update": ["*"],
      "*": ["ValueSet", "CodeSystem", "ConceptMap", "SearchParameter"]
    }
  }

In this file, auditing is enabled with filter_mode set to include. This means that all interactions will be omitted from auditing, except those defined in the interactions section. All interactions involving the Patient will be included in the audit. Additionally, read interactions with Observation and MedicationRequest resources will also be audited.

  {
    "buffer_size": 8,
    "filter_mode": "include",
    "interactions": {
      "*": ["Patient"],
      "read": ["Observation","MedicationRequest"]
    }
  }

Audit Events could also be enabled in the Audit event configuration file. This possibility is left for backwark compatibility with previous Kodjin versions. That is why Audit event configuration file has a higher priority over the global configuration file. Ensure that the enabled: true setting for auditing is specified only once.

RBAC routes configuration file

RBAC routes configuration file allows to manage access to Kodjin endpoints. Current configuration file provides three level of access:

access is allowed without token or scope
access is allowed with active and valid token but no scope is required
access is allowed only with proper scope and valid token

Example of the rbac-routes.json file

{
    "routes": [
        {
            "method": [
                "POST"
            ],
            "path": "/$apply-fhirpath",
            "mode": "token_only"
        },
        {
            "method": [
                "GET",
                "POST"
            ],
            "path": "/$versions",
            "mode": "public"
        },
        {
            "method": [
                "*"
            ],
            "regex": "/metadata(\\?)*[A-Za-z]*",
            "mode": "public"
        },
        {
            "method": [
                "GET"
            ],
            "path": "/fhir-base-url",
            "mode": "public"
        }
    ]
}

How to read and use file:

method is an array, where any kinds of interactions should be mentioned, for example POST, GET. If all kinds of interactions should be used, then * (wildcard) could be used instead. Method is required in the file.
path or regex is a string, where endpoint should be added. Path is an exact match string. Regex allows regex patterns for route path. Path and regex is oneOf element - either path, or regex shall be used.
mode is a string, where only two variant could be used. Any routes that are not mentioned in this file require proper scope for access. Mode is required in the file. Mode variants are:
- "public" - access without token or scope
- "token_only" - access with active and valid token but no scope is required