[
https://issues.apache.org/jira/browse/CALCITE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830599#comment-15830599
]
Josh Elser commented on CALCITE-1539:
-------------------------------------
bq. Sorry I made a mistake in using request.getQueryString() which makes it
confusing. I meant to get the doAs parameter in the query, it should be
something like request.getParameter("doAs").
Gotcha. That makes more sense :)
bq. say we use user guest to authenticate on Knox(Knox demo ldap), and
according to getQueryString() method in
IdentityAsserterHttpServletRequestWrapper.java in Knox, it will put doAs=guest
in the request params
As I'm re-looking at {{AvaticaServerConfiguration#doAsRemoteUser(..)}}, I'm
realizing that the javadoc should be much more clear that the implementation
*must* verify that the caller (Knox, in your example) is allowed to impersonate
the requested user ("guest"). Need to make this very clear otherwise it's a
security hole :)
bq. Knox will redirect request to PQS. In this case, the remote user is Knox
and doAsUser is guest. (correct me if I am wrong)
bq. And to keep public <T> T doAsRemoteUser(String remoteUserName, String
remoteAddress, final Callable<T> action) throws Exception { this method, should
we write another method in Calcite interface to cover the case of doAsUser?
This is what I was trying to point out. {{remoteUserName}} should be {{guest}}
(admittedly, the naming/javadoc aren't as clear as they could be). There is no
need to have a new parameter to this method. Your change should provide the
ability to change how Avatica extracts the {{remoteUserName}} when it invokes
the {{doAsRemtoeUser}} method.
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaProtobufHandler.java#L117-L122
https://github.com/apache/calcite/blob/0938c7b6d767e3242874d87a30d9112512d9243a/avatica/server/src/main/java/org/apache/calcite/avatica/server/AvaticaJsonHandler.java#L122-L127
I would consolidate these two classes to allow for the ability to pass either
{{request.getRemoteUser()}} or a certain parameter from the HTTP request's
query string (as you described in your above example). You would add this
configuration to AvaticaServerConfiguration with a new enumeration to control
this. Something like..
{code}
interface RemoteUserExtractor extends Callable<HttpServletRequest> {
String extractRemoteUser(HttpServletRequest request);
}
/**
* Extract the user this request should execute as.
*/
RemoteUserExtractor getRemoteUserExtractor();
{code}
Then, we can provide two implementations:
{code}
public class HttpRequestRemoteUserExtractor implements RemoteUserExtractor {
public String extractRemoteUser(HttpServletRequest request) {
return request.getRemoteUser();
}
}
public class HttpQueryStringParameterRemoteUserExtractor implements
RemoteUserExtractor {
public String extractRemtoeUser(HttpServletRequest request) {
return request.getParameter("doAs");
}
}
{code}
Does this make sense?
> Enable proxy access to Avatica server for third party on behalf of end users
> ----------------------------------------------------------------------------
>
> Key: CALCITE-1539
> URL: https://issues.apache.org/jira/browse/CALCITE-1539
> Project: Calcite
> Issue Type: Improvement
> Components: avatica
> Reporter: Jerry He
> Assignee: Josh Elser
> Attachments:
> 0001-CALCITE-1539-Enable-proxy-access-to-Avatica-server-f.patch
>
>
> We want to enable proxy access to Avatica server from an end user, but the
> end user comes in via a third party impersonation. For example, Knox and Hue.
> The Knox server user conveys the end user to Avatica.
> Similar things have been done for HBase Rest Sever HBASE-9866 and Hive Server
> HIVE-5155
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
