[Phase 1 - 8.10] Credential validation via direct REST (Hub-triggered, connectors)

[mathias-vandaele]

Summary

Ship credential validation for 8.10 using direct REST from the Hub to the connector runtime (Option 1 in the parent epic). A connector author declares a check once on a configuration class; the Hub calls a runtime endpoint that resolves the stored configuration, runs the check, and returns SUCCESS / FAILURE / UNSUPPORTED at credential-creation time.

This is a complete, correctly engineered solution to a deliberately smaller problem: validating a credential for a runtime the cluster can reach directly. The typed SDK contract connector authors write against does not change when 8.11 swaps the transport for an engine-mediated channel — only the private endpoint underneath it does.

The design is already built and proven on the PoC branch; this ticket tracks hardening it to shippable quality and rolling out adoption.

In scope

• Typed SDK contract ConfigurationValidator (returns success() / failure(code, message); a thrown exception becomes a failure result).
• ConfigurationValidationRegistry — discovers, at startup, every @ConfigurationTemplate class that implements ConfigurationValidator, keyed by template id; duplicate ids fail the registry at startup.
• ConfigurationValidationService — resolves the credentialRef FEEL expression, replaces secrets, deserializes into the registered class, calls validate().
• POST /outbound/configurations/validate — private REST endpoint the Hub calls.
• Element Template Generator changes: @ConfigurationTemplate and PropertyType.Configuration, DSL support, schema validation.
• Connector adoption for the three reference connectors: AWS (via AwsCredentialConfiguration), REST (RestAuthenticationConfiguration), JDBC (JdbcConnectionConfiguration).

Out of scope (8.10)

• Hybrid / outbound-only runtimes, anything behind NAT/firewall, offline Desktop Modeler → deferred to 8.11.
• Trigger from Web Modeler or Desktop Modeler (Hub-triggered only, for cross-surface consistency).
• Re-validation / "last checked" freshness.
• Metadata lookup (dropdowns from live connector data) — removed from PDP-3433 scope.
• Changes to configuration storage or template format (owned by PDP-3396).
• Plain (non-connector) job workers.

Acceptance criteria

• A configuration class can opt into validation by implementing ConfigurationValidator and nothing else.
• At startup, the registry discovers all declared @ConfigurationTemplate + ConfigurationValidator classes; two classes claiming the same template id fail the registry at startup (not at request time).
• POST /outbound/configurations/validate accepts {credentialId, credentialRef, tenantId} and returns {status: SUCCESS | FAILURE | UNSUPPORTED, code?, message?}.
• An unregistered template id returns UNSUPPORTED; a resolution failure or a thrown validator exception returns FAILURE with a code and message.
• Secrets are resolved for the request's tenant; tenant isolation holds (see security note below).
• AWS: AwsCredentialConfiguration.validate() runs a real check (STS GetCallerIdentity) once; bound auth overrides inline auth, bound region drives config, an inline endpoint override is still respected.
• REST: bound authentication overrides inline authentication.
• JDBC: bound connection replaces inline connection fields entirely; exactly one of inline vs bound is present (enforced by a bean-validation constraint).
• A bound configuration overrides the inline value; inline is the fallback — consistent across all three connectors.
• Unit + integration test coverage for registry startup, endpoint contract, secret resolution, and each of the three connectors.

Technical breakdown

Owners are a starting proposal — please confirm/reassign. Only the epic DRI is currently known.

• Connector runtime — ConfigurationValidationRegistry, ConfigurationValidationService, REST controller, Spring wiring. DRI: ?
• Element Template Generator — @ConfigurationTemplate, PropertyType.Configuration, DSL, schema validation. DRI: ?
• Connector adoption — AWS S3 done on PoC; roll out to remaining AWS connectors, REST, JDBC, and other OOTB connectors. DRI: ?
• Security review of out-of-band secret resolution (see note). DRI: ?

SDK contract (for reference)

public interface ConfigurationValidator {
  ConfigurationValidationResult validate();
}

Security note (needs conscious sign-off)

Out-of-band validation runs with no process instance and no element, so there is nothing to scope secret resolution against. ConfigurationValidationService resolves secrets for the request's tenant with SecretFilter.allowAll(). Tenant isolation still applies; process/element-level restriction does not, and cannot, in this path. This is a trade-off inherent to validating outside any process — it needs explicit security sign-off before GA, not a default-into.

Links

• Parent epic: PDP-3433
• Design doc: Implement Kick-Off - Credential Validation in Connectors (8.10)
• Slack: #prj-pdp-3396-connector-credential-manager