R0CKing666 opened a new pull request, #11179: URL: https://github.com/apache/rocketmq/pull/11179
### Which Issue(s) This PR Fixes - Fixes #11178 ### Brief Description The Remoting (TCP) authorization path derives the caller identity from the client-supplied `AccessKey` in the request extFields without any signature verification. `authorizationEnabled` and `authenticationEnabled` are independent switches, so a broker started with authorization on but authentication off would let any client impersonate a known user (including a SUPER user) simply by claiming its AccessKey. This change makes the broker fail-closed: it refuses to start when `authorizationEnabled=true` and `authenticationEnabled=false`, mirroring the existing fail-closed guards in `ProxyAdminAuthInterceptor` for the gRPC admin surface. Changes: - Add `AuthConfig#validate()` that rejects `authorizationEnabled && !authenticationEnabled`. - Call `authConfig.validate()` in `BrokerController#initialRequestPipeline()` before wiring the request pipeline. - Add unit tests for `validate()`. - Add `AccessKeySpoofingReproTest` reproducing the forged-AccessKey authorization path. ### How Did You Test This Change? - `AuthConfigTest`: covers the valid/invalid enable combinations (6 tests pass). - `AccessKeySpoofingReproTest`: reproduces that a forged AccessKey is authorized when authentication is disabled, that an unknown AccessKey is denied, and that enabling authentication rejects the unsigned request (3 tests pass). - Built the `broker` module with `mvn -pl broker -am install -DskipTests` to verify compilation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
