Based on https://docs.google.com/document/d/1bH3hNWXgm6zwHi0C-08cGa_ohd31al06Xbi2b7JjvCo/edit?tab=t.0#heading=h.4k24qhine3oz

The goal of this story is to allow the user to persist tokens to the database and to use them even when a workflow execution is restarted.

Enabling token persistence must be the admin/developer responsibility. For that purpose, the new property quarkus.sonataflow.security.token-persistence is introduced.
The possible values will be:

• None
• Database

The default value must be “None”.

This feature will be implemented by an extension to keep the consistency of the project.

When the value is set to “None” a warning message must be logged indicating that the token persistence is disabled. A similar audit message must be logged.

The responsibility of the data encryption/security is delegated to the owner of the database; the SonataFlow runtime will not insert nor manage encrypted data.

When the token is required, it must be loaded from the DB and be provided to the service needing it.
The token must be associated with the workflow instance ID in the DB for the runtime to be able to retrieve the right token for the right execution: at least 1 new table must be created:

• 1 table that holds the provider name and the associated token provided in the header(s) X-Authorization-<Provider>
  providerName: encrypted String
  token: encrypted String
  (ProcessID: UUID, FK to process table)
• 1 joint table could be introduced to join the previous table and the process table OR the previous table could have the process ID as a foreign key column

The tokens will be stored in their own database schema, separated from the workflow’s schema. This is needed as the feature is implemented by a separate extension.

Upon storing any token, the workflow must log the following information:
Timestamp of the persistence

• Workflow instance ID
• Workflow name
• User identity
  • do not log the token, only the “sub” for JWT tokens (should be an unique identifier) or the username for Basic token contained in it
• Success or failure of the persistence process
  • Log error message too in case of failure

Acceptance criteria

• The documentation of how to use/configure the feature is written
• The new property quarkus.sonataflow.security.token-persistence is made available
• If the property is set to "Database", any value contained in any header X-Authorization-{provider} is stored in the database and may be used even if the workflow execution has been paused and resumed (i.e: pod is restarted, workflow was sleeping, ...).
  • The token will be used with/by the token propagation feature from openapi-generator (https://docs.quarkiverse.io/quarkus-openapi-generator/dev/client.html#_propagation_flow_configuration)
•  Audit log message are created when token is persisted
• The property can be set on the SonataFlowPlatform level to be applied on all deployed workflow (using the managed configmap)