Implement Strict Scheme Enforcement
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 92
- Forks
- 81
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 46
Description
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:
- Security Policy Bypass: It allows clients to bypass the validation at API ML, exposing long-term SAF passwords to backend services.
- 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.
- 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.
httpBasicPassTicketorzoweJwt, the API ML should remove the "authorization basic" header for any routed request. - Logic: The API ML should only allow
Authorization: Basicto pass through if the service is explicitly registered withscheme: bypassor 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing API Mediation Layer request routing and the handling of registered authentication schemes, then inspect where apiml.security configuration is defined and consumed. Define how bypass and strictSchemeEnforcement interact, including defaults, and verify that Basic authorization is removed for non-bypass schemes while legacy passthrough remains supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, authentication, backend, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100