Support for multiple invocations of the same mechanism in a rule without overwriting results

[dadrus]

Preflight checklist

• [x] I agree to follow this project's Code of Conduct.
• [x] I have read and am following this repository's Contribution Guidelines."
• [ ] I have discussed this feature request with the community.

Describe the background of your feature request

Currently, when a rule invokes the same mechanism (e.g., a contextualizer named foo) multiple times, each invocation stores its result under the mechanism’s ID in the Outputs object—overwriting any previous result.

For example, if I use a contextualizer with templated paths to fetch data from different systems, calling it twice within a rule (with different path values) will result in only the last output being available in later steps (e.g., in a finalizer).

This behavior limits flexibility when rules need to reuse the same mechanism and work with multiple, distinct outputs.

Describe your idea

To retain all results from multiple invocations of the same mechanism within a rule and make them uniquely accessible, we could introduce an id field at the step level. heimdall would then store the output of each invocation under this id instead of the mechanism’s name.

For example:

execute:
  - id: system-a
    contextualizer: foo
    config:
      values:
        path: /system-a/some-api
  - id: system-b
    contextualizer: foo
    config:
      values:
        path: /system-b/some-api
  - finalizer: create_jwt
    config:
      claims: |
        {
          "system-a-results": {{ .Outputs.system-a }},
          "system-b-results": {{ .Outputs.system-b }}
        }

This approach avoids overwriting results and ensures that all outputs remain available for later use, such as in finalizers.

Are there any workarounds or alternatives?

To achieve similar functionality with the current setup, you need to duplicate the mechanism definition in heimdall’s config, giving each one a distinct name. While this works, it leads to significant code duplication and config bloat, which in turn makes maintenance more difficult and error-prone.

Version

0.16.0

Additional Context

No response