[AMORO-4117] Implement dashboard RBAC with jCasbin and LDAP role mapping

[xxubai]

Why are the changes needed?

Close #4117.

Amoro Dashboard needs a cleaner RBAC model for multi-user and enterprise environments, especially when login is integrated with LDAP. The previous authorization approach was coarse-grained and difficult to extend.

This patch introduces the first version of Dashboard RBAC based on jcasbin, using LDAP group-to-role mapping as the primary role source. The implementation keeps the privilege model intentionally small while making role capabilities policy-driven and frontend authorization privilege-driven.

Brief change log

• Introduce jcasbin-based Dashboard authorization.
• Change the role model from fixed Java enum semantics to string-based roles.
• Keep built-in roles SERVICE_ADMIN and VIEWER.
• Keep the privilege set intentionally small:
  • VIEW_SYSTEM
  • VIEW_CATALOG
  • VIEW_TABLE
  • VIEW_OPTIMIZER
  • MANAGE_CATALOG
  • MANAGE_TABLE
  • MANAGE_OPTIMIZER
  • EXECUTE_SQL
  • MANAGE_PLATFORM
• Resolve effective privileges from Casbin policy and return both roles and privileges from /login/current.
• Switch frontend authorization to privilege-based control for menus, route guards, and write actions.
• Support LDAP group-to-role mapping under http-server.authorization.ldap-role-mapping.groups.
• Allow custom role names through policy and group mapping, without adding new Java role enums.
• Externalize Dashboard request-to-privilege mapping into a built-in resource configuration file.
• Keep built-in Casbin model and default policy resources loaded from classpath.
• Update configuration and design documents to match the current RBAC model.

Role design

Role	Description	Privileges
SERVICE_ADMIN	Platform-level administrator	All privileges
VIEWER	Read-only resource viewer	VIEW_CATALOG, VIEW_TABLE, VIEW_OPTIMIZER

Custom role names are also supported when they are defined by Casbin policy and resolved from LDAP group mapping. Example: OPERATOR.

Privilege design

Privilege	Description
VIEW_SYSTEM	View system-level pages such as overview, version, and health status
VIEW_CATALOG	View catalog list and catalog details
VIEW_TABLE	View table details, partitions, snapshots, and optimization history
VIEW_OPTIMIZER	View optimizers, resource groups, and optimization status
MANAGE_CATALOG	Create, update, and delete catalogs
MANAGE_TABLE	Upgrade tables, cancel optimization, and update table properties
MANAGE_OPTIMIZER	Create and release optimizers, manage resource groups
EXECUTE_SQL	Execute SQL in Terminal
MANAGE_PLATFORM	Manage system settings, API tokens, and platform files

Custom role example

A custom role can be introduced by policy and LDAP group mapping.

Policy example:

p, OPERATOR, CATALOG, GLOBAL, VIEW_CATALOG, allow
p, OPERATOR, CATALOG, GLOBAL, MANAGE_CATALOG, allow
p, OPERATOR, TABLE, GLOBAL, VIEW_TABLE, allow
p, OPERATOR, TABLE, GLOBAL, MANAGE_TABLE, allow
p, OPERATOR, OPTIMIZER, GLOBAL, VIEW_OPTIMIZER, allow
p, OPERATOR, OPTIMIZER, GLOBAL, MANAGE_OPTIMIZER, allow

LDAP mapping example:

- group-dn: "cn=operator,ou=groups,dc=example,dc=com"
  role: OPERATOR

How was this patch tested?

• Add some test cases that check the changes thoroughly including negative and positive cases if possible
• Add screenshots for manual tests if appropriate
• Run test locally before making a pull request

Test details:

• Added and updated unit tests for role resolution, LDAP group role mapping, and privilege resolution.
• Verified backend compile, frontend build, and test compile locally.
• Ran:
  • mvn -pl amoro-ams -am -DskipTests compile
  • mvn -pl amoro-ams -am -DskipTests test-compile

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? docs

[zhoujinsong]

Thanks for the PR! A few thoughts:

1. Consider using jCasbin for the permission model

There is a prior PR #3544 that implemented readonly user support using jCasbin. The jCasbin approach has some advantages worth considering:

• Permission rules are externalized from code — adding new roles or changing resource granularity only requires policy changes, not code changes
• A unified enforcer intercept is more reliable than manually maintaining per-endpoint checks in DashboardServer, which is easy to miss
• It opens the door for future fine-grained resource permissions (e.g., per-catalog access control) without a major refactor

The complexity of integrating jCasbin is not high (PR #3544 shows +254/-37), and it would make the permission layer more extensible and maintainable.

[xxubai]

1. Consider using jCasbin for the permission model

Hi @zhoujinsong . I refactor this PR base on your suggestion. PTAL.