xxubai opened a new issue, #4117:
URL: https://github.com/apache/amoro/issues/4117
### Description
Add role-based access control (RBAC) to the Amoro Dashboard, supporting two
roles: **ADMIN** (full access) and **READ_ONLY** (view-only). This enables
organizations to restrict write operations (catalog management, optimizer
control, SQL execution, etc.) to authorized administrators while allowing other
users read-only access.
### Use case/motivation
Currently, all authenticated Dashboard users have full admin privileges. In
multi-tenant or enterprise environments (e.g., Cisco AD/LDAP), this poses
security risks:
- Any authenticated user can create/delete catalogs, manage optimizers, and
execute arbitrary SQL.
- There is no way to differentiate between operators and viewers.
- Organizations using LDAP need a mechanism to map LDAP groups to Amoro
roles without maintaining a separate user database.
### Describe the solution
Implement a lightweight, built-in RBAC system with no additional third-party
dependencies:
### Backend (Java)
1. **`Role` enum** — Defines `ADMIN` and `READ_ONLY` roles.
2. **`RoleResolver`** — Resolves user roles at login time with the following
priority:
- Local `authorization.users` list (username + role)
- `authorization.admin-users` whitelist
- Built-in admin username (`ams.admin-username`)
- LDAP group membership (via `LdapGroupRoleResolver`)
- Fall back to `authorization.default-role`
3. **`LdapGroupRoleResolver`** — Queries LDAP group membership using JNDI to
determine if a user belongs to the configured admin group DN.
4. **`LoginController`** — Returns the resolved role in the login response
(`SessionInfo`). Separates authentication errors from role-resolution errors
with clear, user-friendly messages.
5. **`DashboardServer`** — Enforces role-based access on API endpoints:
`READ_ONLY` users receive HTTP 403 on write operations.
### Frontend (Vue/TypeScript)
1. **`permission.ts`** — Utility to check `isReadOnly` from the user store.
2. **UI guards** — Buttons for catalog creation/deletion, optimizer
management, SQL terminal execution, and table operations are hidden or disabled
for `READ_ONLY` users.
3. **Login response** — Stores the `role` field from the login API in the
user store.
### Configuration
All authorization settings are under `ams.http-server.authorization`:
```yaml
ams:
http-server:
authorization:
enabled: true
default-role: READ_ONLY
admin-users:
- alice
ldap-role-mapping:
enabled: true
admin-group-dn: "CN=amoro-admins,OU=Groups,DC=example,DC=com"
group-member-attribute: "member"
user-dn-pattern: "uid={0},ou=people,dc=example,dc=com"
bind-dn: "cn=service-account,dc=example,dc=com"
bind-password: "service-password"
```
### Key design decisions
- **Default off** — `authorization.enabled` defaults to `false`; existing
deployments are unaffected.
- **No third-party deps** — Uses only JDK built-in JNDI for LDAP queries.
- **Fail-fast on config errors** — LDAP bind failures (e.g., wrong password)
throw exceptions instead of silently downgrading users to READ_ONLY.
- **`admin-group-dn` requires full DN** — Simplifies code by removing the
search-by-name path; users must provide the complete distinguished name.
### Subtasks
_No response_
### Related issues
_No response_
### Are you willing to submit a PR?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://www.apache.org/foundation/policies/conduct)
--
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]
