tju-yxq opened a new issue, #5311:
URL: https://github.com/apache/rocketmq-dashboard/issues/5311
## Problem
The operation audit records every business mutation — topic changes, ACL
edits, credential rotations, settings saves — but nothing about the
**authentication surface**. Who logged in, and when? Who failed a login, and
against which username? Who logged out? Who disabled an account, reset
someone's password, or revoked their sessions? None of it leaves a trace. The
audit trail starts one layer too late: it can prove an operator changed a
topic, but cannot prove how that operator authenticated, or who wielded the
user-management powers that grant access in the first place.
These are the first questions an incident review or a compliance audit asks
("show me the login history for this account", "who disabled the departed
admin"), and today the answer is: the console's own audit page has no such rows.
## Current behavior and reproduction
1. Open **Ops > Audit Logs** and note the operation types in the filter:
business mutations only.
2. Sign out and back in: no LOGIN row appears.
3. Enter a wrong password a few times: no FAILURE row appears.
4. As an administrator, create a user, disable an account, reset a password,
revoke sessions from the user management page: none of these operations appear
in the audit feed.
5. Ask the audit page who reset a specific account's password last quarter:
the information was never recorded.
Code facts:
`server/src/main/java/org/apache/rocketmq/studio/auth/AuthController.java`
handles `/api/auth/login`, `/logout` and `/password` without any
`OperationAuditService` reference, and `StudioUserController.java` (the
create/status/password/revoke endpoints, around lines 73-99) likewise.
`OperationAuditService` is used by eleven services across the repo —
`AuthService` and the two auth controllers are the notable absentees.
## Proposed behavior
- LOGIN is recorded on success and failure, with the **attempted username**
as the operator (no request context exists before authentication; the attempted
name is the security-relevant actor).
- Failure rows carry the message the service answered — the uniform "Invalid
username or password" for the 401 family and the rate-limiter's 429 text — so
account-existence is never leaked through the audit table either.
- LOGOUT is recorded; the self-service password change records
UPDATE_OWN_PASSWORD.
- User management records CREATE_USER, UPDATE_USER_STATUS,
RESET_USER_PASSWORD and REVOKE_USER_SESSIONS with the affected account and the
outcome in the detail (`admin=`, `enabled=`, `revoked=`). No password material
is ever recorded.
- Recording happens at the controller boundary, where the request context
provides the acting operator for authenticated calls; audit failures stay
swallowed (`record()` already logs and continues), so an audit outage can never
break login.
- `OperationAuditService` gains an operator-explicit `record` overload for
events outside an authenticated thread; the existing context-based method
delegates to it.
## Acceptance criteria
- [ ] A successful login records LOGIN/SUCCESS with the attempted username
as operator.
- [ ] A failed login records LOGIN/FAILURE with the same uniform message the
API answered.
- [ ] A rate-limited login records LOGIN/FAILURE with the 429 message.
- [ ] Logout records LOGOUT; the self-service password change records
UPDATE_OWN_PASSWORD.
- [ ] Create, status change, admin password reset and session revocation
each record their operation with the affected account and outcome detail.
- [ ] No recorded field ever contains a password or token.
- [ ] An audit persistence failure during login does not change the login
response.
- [ ] The existing business-mutation audit rows are unchanged.
## Importance
Must-have. This is the standard table-stakes set for an audited operational
console: authentication events and account-lifecycle changes are precisely what
auditors and incident responders request first. Workaround today: correlate
server logs by hand — the application log carries login lines but is rotated
away, unfilterable, and shows nothing for user-management mutations.
## Duplicate check
Searched open and closed issues and PRs for `login audit`, `audit user
management`, and `authentication events audit`. The adjacent closed work (#1005
non-admin invocation hardening, #3046 login lockouts, #4159 uniform login
responses) hardened behavior but never added audit records; nothing proposes
auditing the auth surface.
--
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]
