Fetch Additional User Details on Authentication

[shohamyamin]

This feature request aims to enhance user authorization by fetching additional user details during authentication. These details, stored in the user session, would be available for query execution, particularly for access control decisions. For example, attributes could be used with OPA (Open Policy Agent) to determine whether a user has access to a specific table.

Proposed Solution:

1. External API: Integrate with any API that implements a Trino User Attribute Fetcher API Interface (e.g., identity management systems).
2. LDAP/AD Integration: Fetch user details directly from LDAP or Active Directory during authentication.
3. Trino Catalog: If that information exists in one of the catalogs, execute a predefined query to fetch user attributes from a Trino catalog.

These integrations would allow flexible retrieval of user-specific data and store it in the session for later use.

Benefits:

• Enhanced Authorization: User attributes can be used for fine-grained access control, such as determining table access with OPA.
• Enhanced Query Context: Provides more personalized query execution based on user details.
• Simplified Auditing: Makes user attributes easily accessible for auditing and access control.

Additional Considerations:

• Scalability: Integrate caching and rate-limiting to minimize performance impact during authentication.

[Praveen2112]

cc: @dain

[dain]

We have been talking about adding a new properties bag to io.trino.spi.security.Identity, similar to Map<String, String> extraCredentials that is explicitly not "credential". Instead it would just be a bag of extra authenication properties. We would fill this bag with data from oauth token, ldap, and so on, as part of authentication. Since this information is part of the user identity, it would be available to all SPI interfaces that take an identity (virtually all calls).

Additionally, since it is not security sensitive, we could even add functions to Trino to extract this information as part of query, which is super useful for security row filters, and column masking.

[dain]

BTW, I am not fan of the idea of supporting "Trino Catalog" as an option. This would require a complex ordering in the authentication system. I have also had a bad experience using Trino queries automatically from Trino plugins. You end up with the system flooding itself, which can have nasty knock on effects to things like query logging.