DISCUSSION: user impersonation / bearer token authorization #884
Conversation
use bearer token in header and strip out the bearer token in the jdbc url if one if present in the header
|
Hi @justin2004, thank you for opening this discussion on user impersonation with a concrete implementation. It is indeed an important topic and currently Ontop is missing the right abstractions to handle it. Your PR handles the particular case of using the JWT authentication of Trino, where the JWT token is directly passed to Ontop as a bearer token in the HTTP Authorization header and Ontop directly passes it to Trino without doing any authentication on its side. So here the user query the Ontop SPARQL endpoint with the credentials for another service, Trino. I foresee that a general solution for user impersonation should also support:
Interestingly, this capability is about to arrive in the Postgres world, with PG 18. It is common with Databricks and Snowflake. I think the An alternative architecture would be to use Ontop as a query reformulation service and then have the client send the generated SQL query directly to Trino, if the latter is directly reachable by the client. However, at the moment, the generated SQL query doesn't perfectly match the SPARQL query as an extra post-processing step is needed. We are planning to add this capability next year. |
|
How about adding support to that to the databricks connector ? |
|
@giovannidegani what kind of http header to you need to pass through to databricks? |
if you have multiple users with varying access to the underlying data stores (trino, postgres, etc.) it can be necessary to allow ontop to impersonate each user running queries.
currently in a properties file if you do something like:
it allows ontop to initialize BUT then ontop can't impersonate the user that runs the SPARQL query.
this PR allows you to set your properties like like the example but then if a query to ontop arrives with an HTTP
Authorization: bearer BEARER_TOKEN_HEREheader then it will remove theaccessTokenfrom the JDBC URL and it will append theAuthorizationheader to the outgoing SQL query (thereby allowing ontop to run SQL as user X).this approach is specific to trino with OAUTH authentication so i don't expect it to be merged as is but perhaps it could lead to a more general user impersonation solution.