bug: Fix OIDC authentication and namespace authorization in Runner

[gmunozfe]

Pre-flight

• I’m using the latest release or a recent snapshot.
• I searched existing issues and Discussions.

What happened?

Runner registers ApiKeyAuthenticationMechanism and PermitAllAuthenticationMechanism as CDI alternatives. This causes them to replace Quarkus-provided authentication mechanisms, preventing OIDC bearer authentication from creating a valid SecurityIdentity.

After enabling OIDC authentication, namespace authorization exposed two additional issues:

• OIDC namespace claims may be represented as JSON objects instead of regular Java strings. In this case, the comparison is failing.
  For example, authorizedNamespaces.contains("team-a") is failing because it is comparing String "team-a" against JSON-P JsonString "team-a".

• OIDC users without a namespace claim were incorrectly allowed to access all namespaces. They are now denied unless they have the administrator role.

  This interpretation is more restrictive and distinguishes between security modes:

  • In NONE or unrestricted API-key configurations, no namespace information can still mean unrestricted access.

  • For an OIDC invoker, a missing or empty namespace claim means the user has not been assigned any namespace, so access is rejected.

  • An OIDC administrator can still access all namespaces without the claim.

Minimal reproducer

Run security tests on Quarkus-flow Openshift testsuite

Quarkus version

3.33.2

quarkus-flow version

1.0.0-SNAPSHOT

Java version

21

Runtime

None

Quarkus extensions in use

No response

Relevant logs/stack traces

[ricardozanini]

@gmunozfe about this:

For an OIDC invoker, a missing or empty namespace claim means the user has not been assigned any namespace, so access is rejected.

It's not true. If no namespace is added to the claim, it means that the user can access everything. Otherwise, it will be a pain to assign roles to every user everywhere on a multi-namespace distributed system.