Access File Authorizer Connections

The Access File Authorizer (AFA) requires credentials to connect to external components such as databases, Redis, and other services used during authorization flows and job processing.

AFA integrates with the PlainID Secret Management (SM) service. This enables credentials to be configured using secret references while preserving the standard environment-variable configuration pattern used across PlainID services.

In the following examples, configuration snippets show environment variables as defined in the default config.yaml. These environment variables can contain Secret Management references using the standard syntax.

Refer to Installing and Configuring the Access File Authorizer for more information about the Authorizer and how you can use the SM syntax.

Secret Management Configuration

The Access File Authorizer integrates with the PlainID Secret Management (SM) service to resolve secret references at runtime.

To enable this integration, configure the secretManager section in the Authorizer config.yaml:

secretManager:
  useInConfiguration: ${SECRET_MANAGER_ENABLED:true}
  apiClient:
    url: ${SECRET_MANAGER_URL}
    timeout: ${SECRET_MANAGER_TIMEOUT:40s}
  cacheManager:
    ttl: ${SECRET_MANAGER_CACHE_TTL:1h}
  returnEmptyValueOnError: 
  ${SECRET_MANAGER_RETURN_EMPTY_VALUE_ON_ERROR:true}
  retryTimeoutOnError: ${SECRET_MANAGER_RETRY_TIMEOUT_ON_ERROR:30s}

Parameters

Parameter	Description
`useInConfiguration`	Enables resolving Secret Management references in configuration values
`apiClient.url`	Secret Management service endpoint. The Secret Management Service used by the Authorizer. This URL should be exposed in the Secret Management instance, which is deployed as part of the PAA.
`apiClient.timeout`	Timeout for Secret Management API calls
`returnEmptyValueOnError`	Returns empty values if secret resolution fails instead of failing execution
`retryTimeoutOnError`	Time to wait before retrying failed secret retrieval
`cacheManager.ttl`	Cache duration for resolved secrets. The secret is refreshed after sending a request to the Secret Management service.

Note: The Secret Management Service must be deployed as part of the PAA and accessible for secret resolution to function correctly.

Secret Reference Syntax

Secrets are referenced using the Secret Management syntax:

{{store=<storeID>,key=<secretName>,refreshInterval=<interval>}}

Parameters

Parameter	Description
`store`	The ID defined in the Secret Management service configuration.
`key`	The secret key name to retrieve from the store.
`refreshInterval`	Optional refresh interval for retrieving updates from the store. Supported units are seconds (`s`), minutes (`m`), hours (`h`), and days (`d`).

Example environment variable configuration:

DB_PASS={{store=AZURE_KEY_VAULT_STORE,key=db-password}}

Redis Configuration

The Authorizer uses Redis as part of its job scheduler. Redis configuration can utilize the secret key syntax to securely retrieve credentials.

redis:
  host: ${REDIS_HOST:localhost}
  port: ${REDIS_PORT:6379}
  username: ${REDIS_USER:}
  password: ${REDIS_PASS}
  db: ${REDIS_DB:0}
  ssl: ${REDIS_SSL_ENABLED:false}

Example:

REDIS_PASS={{store=AZURE_KEY_VAULT_STORE,key=redis-password}}

Operational Database Configuration

The Authorizer connects to an operational database as part of its runtime processing. The database username and password support configuration via Secret Management.

db:
  username: ${DB_USER}
  password: ${DB_PASS}

Example:

DB_USER={{store=AZURE_KEY_VAULT_STORE,key=db-username}}
DB_PASS={{store=AZURE_KEY_VAULT_STORE,key=db-password}}

Data Source Database Credentials

Datasource definitions used by the Authorizer support secret-based configuration for database credentials.

datasources:
  ds1:
    username: ${DS1_DB_USER}
    password: ${DS1_DB_PASS}

Example:

DS1_DB_USER={{store=AZURE_KEY_VAULT_STORE,key=ds1-db-user}}
DS1_DB_PASS={{store=AZURE_KEY_VAULT_STORE,key=ds1-db-password}}

PDP Client Credentials

The Authorizer uses PDP client credentials when interacting with PDP runtime service. These credentials support configuration via Secret Management.

clientId: ${FLOW1_PDP_RUNTIME_PARAMETERS_CLIENT_ID}
clientSecret: ${FLOW1_PDP_RUNTIME_PARAMETERS_CLIENT_SECRET}

Example:

FLOW1_PDP_RUNTIME_PARAMETERS_CLIENT_ID={{store=AZURE_KEY_VAULT_STORE,key=pdp-client-id}}
FLOW1_PDP_RUNTIME_PARAMETERS_CLIENT_SECRET={{store=AZURE_KEY_VAULT_STORE,key=pdp-client-secret}}

Webhook Headers

The Authorizer supports webhook integrations. HTTP header values defined for webhooks support Secret Management, including authorization headers.

webhooks:
  copyFileWebhook:
    method: "POST"
    headers:
      - name: Content-Type
        values: ["application/json"]
      - name: Authorization
        values: ["{{store=AZURE_KEY_VAULT_STORE,key=afarclone}}"]

RClone Authorization

When the Authorizer is configured to use RClone, the authorization header supports secret-based configuration.

Authorization: basic {{store=AZURE_KEY_VAULT_STORE,key=rclone-basic-auth}}

Error Logging

If secret keys are configured and the Secret Management service is not available, AFA prints relevant error logs to assist with monitoring and troubleshooting.

AccessFile (AFA) supports Secret Management for credentials used by Redis, operational databases, datasource databases, PDP client configuration, webhook headers, and RClone authorization.