Implement Strict Scheme Enforcement

[achmelo]

Problem Statement

Currently, the API Mediation Layer (ML) acts as a transparent proxy for Authorization: Basic headers if it cannot perform a transformation (e.g., when a client sends a raw password instead of a Zowe JWT).

Even when a service is registered with authentication.scheme: httpBasicPassTicket, the Gateway allows raw user:password credentials to pass through to the backend service. This behavior presents several risks:

1. Security Policy Bypass: It allows clients to bypass the validation at API ML, exposing long-term SAF passwords to backend services.
2. Loss of Isolation: A compromise of a "trusted" backend service (onboarded via mTLS) results in the theft of global mainframe credentials rather than short-lived, application-specific PassTickets.
3. Non-Conformance: It allows for "Shadow Authentication" that does not meet Zowe SSO Conformance criteria, leading to an inconsistent security posture across the ecosystem.

Proposed Change

API ML should enforce the "Scheme Integrity" declared during service onboarding.
We propose the introduction of Strict Scheme Enforcement:

• Behavior: If a service is registered with authentication scheme, e.g. httpBasicPassTicket or zoweJwt, the API ML should remove the "authorization basic" header for any routed request.
• Logic: The API ML should only allow Authorization: Basic to pass through if the service is explicitly registered with scheme: bypass or if a new "strictSchemeEnforcement" flag is false.

Suggested Configuration

To maintain backward compatibility for environments that rely on legacy passthrough, we suggest a new property:

YAML

apiml:
  security:
    strictSchemeEnforcement: true # Default could be false for LTS, true for next major

Benefits

Ensures that the "master" password never leaves the Gateway memory for services intended to be SSO-conformant
Aligns the API ML’s behavior with the metadata defined in the service registration.