Fix user impersonation with presto #9422
Conversation
|
@john-bodley this might be interesting to you |
There was a problem hiding this comment.
Looking at dropbox/PyHive#309 I'm unsure that setting principle_username provides any additional value over simply setting the url.username per the Presto logic here if user impersonation is enabled.
| self.db_engine_spec.modify_url_for_impersonation( | ||
| sqlalchemy_url, self.impersonate_user, effective_username | ||
| ) | ||
| if not user_name or not str(sqlalchemy_url).startswith('presto'): |
There was a problem hiding this comment.
There shouldn't be any database specific logic in core.py hence the reason for the self.db_engine_spec.modify_url_for_impersonation(...) method. You should do something like this.
| @@ -313,6 +314,9 @@ def get_sqla_engine( | |||
| if connect_args: | |||
| params["connect_args"] = connect_args | |||
|
|
|||
| if user_name and self.impersonate_user and str(sqlalchemy_url).startswith('presto'): | |||
There was a problem hiding this comment.
See ^^. You should update get_configuration_for_impersonation to handle this. Note given that this isn't part of the connection key the get_configuration_for_impersonation needs be refactored to be get_connection_args_for_impersonation.
|
@john-bodley current behavior before this pr seems to modify username in url so it expects all users to have same password as the generic acct !? |
|
@tooptoop4 you could do something similar to #9405 to achieve what you require which also updates |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
|
crispy |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
|
@tooptoop4 curious to know why this PR was ever merged to superset branch? |
|
@DRavikanth I'm not a committer |
CATEGORY
Choose one
SUMMARY
Fixes #9406
PyHive 0.6.2 release includes dropbox/PyHive#309 making this change possible.
In presto, credentials are authenticated against a 'principal', that principal can then impersonate a 'user' so queries can be executed with authorisation rules applied to the user (not the principal).
Benefit: a single shared presto data source can be created in superset with a generic account (superuser aka the principal) in the presto connection. Then each user that logs into superset ui does not need to create new datasource, they can go straight to SQLLab and run presto queries on the shared datasource which are being authorised under their username.