fzhsbc opened a new issue, #11307:
URL: https://github.com/apache/gravitino/issues/11307
### Describe the feature
I would like to propose an official Gravitino integration path for enforcing
Gravitino RBAC from Trino's authenticated session identity, especially for
BI/JDBC/ODBC deployments.
Gravitino already has Trino connector authentication and session forwarding
support, including `gravitino.client.session.forwardUser=true` for simple auth.
That is useful, but it still leaves an important deployment gap:
- Trino is often the system that authenticates end users, for example
through password, OAuth2, LDAP, Kerberos, or an enterprise gateway.
- BI tools such as PowerBI, Superset, Looker, JDBC, or ODBC clients may not
be able to forward a Gravitino-audience OAuth token reliably to Gravitino.
- In those deployments, the trusted identity boundary is Trino's
authenticated `Identity`, not a user name or token self-reported by the
downstream client.
- Gravitino RBAC should still be the policy source for metadata objects,
instead of maintaining a second policy system only in Trino.
### Motivation
For a multi-user Trino deployment backed by Gravitino, a common desired flow
is:
```text
BI/JDBC/ODBC user -> Trino authentication -> Trino Identity -> Gravitino
RBAC authorization -> query allowed/denied
```
The security property we need is: the user name sent to Gravitino for an
authorization decision must be derived from Trino's authenticated session
identity and accepted only from a trusted Trino service principal.
Forwarding a user token to Gravitino is not always practical because some
BI/ODBC clients cannot provide a suitable Gravitino-audience OAuth token.
Forwarding only a client-supplied user name is also not sufficient unless Trino
has already authenticated and bound that name to the session identity.
### Describe the solution
A possible upstream-friendly design could include the following pieces:
1. A Gravitino-side delegated authorization API, for example:
```text
POST /api/metalakes/{metalake}/authorize
```
The request would contain the target end user, metadata object, privilege,
and optional audit context such as Trino query ID. The endpoint should only
accept requests from configured trusted service principals, such as a Trino
coordinator service account.
2. A documented Trino integration using Trino's `SystemAccessControl` SPI.
Trino's SPI already provides hooks such as `checkCanSelectFromColumns`,
`checkCanInsertIntoTable`, `checkCanCreateTable`, `checkCanDropTable`,
`checkCanDeleteFromTable`, and `checkCanUpdateTableColumns`. A
Gravitino-provided or documented SystemAccessControl plugin could translate
those checks into Gravitino metadata objects and privileges such as
`USE_CATALOG`, `USE_SCHEMA`, `SELECT_TABLE`, `MODIFY_TABLE`, `CREATE_TABLE`,
`CREATE_VIEW`, etc.
3. A clear separation between service authentication and end-user
authorization.
The Trino service authenticates to Gravitino using a service credential. The
end user is not authenticated to Gravitino by presenting a token directly;
instead, Gravitino authorizes the end user only because the request comes from
a trusted Trino principal and Trino has already authenticated the session user.
4. Security requirements documented explicitly:
- Trino must enable real user authentication; anonymous/shared-user
deployments cannot provide per-user RBAC.
- Trino must prevent user spoofing through user mapping / impersonation
controls.
- Gravitino should fail closed if the delegated authorization request cannot
be validated.
- The Gravitino audit log should record both the trusted caller and
delegated end user.
### Alternatives considered
- **Only use connector session forwarding**: useful when Trino can forward a
suitable user identity or token to Gravitino, but it does not fully address
BI/ODBC deployments where Gravitino-audience user tokens are unavailable.
- **Require BI clients to forward OAuth tokens to Gravitino**: not always
practical and couples BI client capabilities to Gravitino authentication
details.
- **Maintain policies only in Trino**: works technically through Trino
access control, but duplicates Gravitino RBAC and risks policy drift.
- **Trust a user name directly from the client**: unsafe unless Trino
authenticates and binds that user name first.
### Additional context
Related work:
- #10003 added Gravitino server authentication support for the Trino
connector.
- #10559 and #10730 added session user forwarding for the Gravitino Trino
connector.
This proposal is narrower than a generic token translation service. It
focuses on the case where Trino is the trusted query engine and Gravitino
remains the central RBAC policy decision point for metadata objects.
--
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]
