[I] [security] Support group-based ACL authorization for authenticated identities [fluss]

["litiliu (via GitHub)" <gi...@apache.org>]

litiliu opened a new issue, #3829:
URL: https://github.com/apache/fluss/issues/3829

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.
   
   
   ### Motivation
   
   Fluss ACL entries can represent principals such as `User`, `Group`, and `Role`, but the current authentication and authorization path only carries and evaluates one `FlussPrincipal`.
   
   For example, SASL/PLAIN always creates one `User` principal from the authorization ID. `Session` stores only that principal, and `DefaultAuthorizer` evaluates ACLs only against `session.getPrincipal()`.
   
   This prevents an authenticated identity from carrying group membership such as:
   
   ```text
   User:alice
   Group:data-engineers
   Group:fluss-readers
   ```
   
   This is particularly relevant to [#3495](https://github.com/apache/fluss/issues/3495), where a validated JWT can provide the user identity through `sub` and group membership through a `groups` claim. Mapping only `sub` to a single `FlussPrincipal` cannot support group-based ACL policies.
   
   This feature should provide authentication-mechanism-independent support for additional principals. It should be usable by OAUTHBEARER, Kerberos, mTLS, LDAP, and custom authentication plugins rather than being implemented only inside the OAuth mechanism.
   
   Related design: [FIP-2: Fluss Authentication and Authorization](https://cwiki.apache.org/confluence/display/FLUSS/FIP-2%3A+Fluss+Authentication+and+Authorization).
   
   ### Solution
   
   Extend the authenticated session identity from one primary principal to:
   
   - One primary principal, preserving the existing `Session#getPrincipal()` behavior.
   - Zero or more additional principals, such as `Group` or `Role`.
   - An immutable, validated, and deduplicated collection of all authenticated principals.
   
   Preserve source compatibility for existing authentication plugins, for example through a default server-authenticator method that returns no additional principals.
   
   Update the default authorizer so an operation is allowed when the existing resource, operation, and host rules match an `ALLOW` ACL for any authenticated principal. Existing SASL/PLAIN behavior must remain unchanged because it produces only the primary `User` principal.
   
   OAUTHBEARER support from #3495 can then map:
   
   ```text
   sub -> primary User principal
   groups[] -> additional Group principals
   ```
   
   The implementation should also define which identity is used for logs and user metrics, avoid logging JWTs or credentials, and bound the number and size of additional principals.
   
   Add tests covering:
   
   - Existing single-user SASL/PLAIN authorization behavior.
   - Authorization granted through a Group ACL.
   - Multiple groups where only one matches.
   - No matching user or group ACL.
   - Duplicate and empty group values.
   - Preservation of resource, operation, and host matching.
   - Backward compatibility for authentication plugins that return only one principal.
   
   ### Anything else?
   
   This proposal adds group-based ACL authorization. It does not introduce a complete RBAC management system with role creation, user-to-role assignment, role hierarchies, or role lifecycle APIs. Those capabilities can be designed separately if needed.
   
   ### Willingness to contribute
   
   - [ ] I'm willing to submit a PR!


-- 
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: issues-unsubscribe@fluss.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org