[Feature]: Dashboard RBAC Permission Control with LDAP Group Mapping

[xxubai]

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:

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?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct