You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Depending on the way a user attempts to impersonate another, the checkCanImpersonateUser method on System Access Control SPI may get the original (authenticated principal) user's groups or not.
Using a session user (e.g. --session-user on the CLI): the authenticated identity's groups are not loaded
Using SET SESSION AUTHORIZATION: the authenticated identity's groups are loaded - I imagine because the authenticated identity had a session already, which they used to execute the SET SESSION AUTHORIZATION query in the first place
User roles are always loaded such that rules can be written to control impersonation privileges based on roles. However, the same is not done for user groups - which is problematic when trying to move all authorization to a system like OPA (#19532 )
Three ideas that come to mind to fix this:
1. Implement group retrieval on the SessionContext factory and on Session build
There seem to be 2 places where groups would need to be loaded:
extractAuthorizedIdentity in HttpRequestSessionContextFactory: used in several different contexts including controlling UI operations
2. Implement impersonation checks on the SessionContext factory
I am not as familiar with this part of the code, so please correct me if I'm wrong.
It seems to me that SessionContext is built by HttpRequestSessionContextFactory, and most fields are final. As such, we could just refuse to build a SessionContext for this query if the user is unable to impersonate the target user - and remove any impersonation checks in createSession
If we want to add other SessionContextFactory's in the future, they would need to behave in the same way, as the session would no longer be responsible for such impersonation checks.
While this feels like a nice addition, I feel like it is against the way that the rest of the codebase works (i.e. the servlet utils are quite lightweight and all operations around groups are done at the session level)
The text was updated successfully, but these errors were encountered:
Similar to #12953
Depending on the way a user attempts to impersonate another, the
checkCanImpersonateUser
method on System Access Control SPI may get the original (authenticated principal) user's groups or not.--session-user
on the CLI): the authenticated identity's groups are not loadedSET SESSION AUTHORIZATION
: the authenticated identity's groups are loaded - I imagine because the authenticated identity had a session already, which they used to execute theSET SESSION AUTHORIZATION
query in the first placeUser roles are always loaded such that rules can be written to control impersonation privileges based on roles. However, the same is not done for user groups - which is problematic when trying to move all authorization to a system like OPA (#19532 )
Three ideas that come to mind to fix this:
1. Implement group retrieval on the SessionContext factory and on Session build
There seem to be 2 places where groups would need to be loaded:
extractAuthorizedIdentity
inHttpRequestSessionContextFactory
: used in several different contexts including controlling UI operationstrino/core/trino-main/src/main/java/io/trino/server/HttpRequestSessionContextFactory.java
Lines 217 to 226 in ba88ce0
createSession
inQuerySessionSupplier
: used when building the actual sessiontrino/core/trino-main/src/main/java/io/trino/server/QuerySessionSupplier.java
Lines 78 to 95 in ba88ce0
If we implement group retrieval in both these places, authorization checks should be able to use them
For a draft, see: https://github.com/bloomberg/trino/tree/add-groups-for-impersonation-in-context-and-session
Link to the commit: bloomberg@8f3efba
2. Implement impersonation checks on the SessionContext factory
I am not as familiar with this part of the code, so please correct me if I'm wrong.
It seems to me that
SessionContext
is built byHttpRequestSessionContextFactory
, and most fields arefinal
. As such, we could just refuse to build aSessionContext
for this query if the user is unable to impersonate the target user - and remove any impersonation checks increateSession
If we want to add other
SessionContextFactory
's in the future, they would need to behave in the same way, as the session would no longer be responsible for such impersonation checks.Would this be an option?
For a draft, see: https://github.com/bloomberg/trino/tree/add-groups-for-impersonation-in-context
Link to the commit: bloomberg@b015266
3. Loading groups when retrieving the authenticated identity
We could add groups to the global authenticated identity set on the servlet request by the
AuthenticationFilter
trino/core/trino-main/src/main/java/io/trino/server/security/AuthenticationFilter.java
Line 105 in ba88ce0
While this feels like a nice addition, I feel like it is against the way that the rest of the codebase works (i.e. the servlet utils are quite lightweight and all operations around groups are done at the session level)
The text was updated successfully, but these errors were encountered: