Larry,
I found the culprit! It appears that the ordering of policies matters in
service.xml. I modified mine to:
<policies>
<policy role="webappsec" />
<policy role="federation" name="SSOCookieProvider" />
<policy role="rewrite" />
</policies>
It was originally:
<policies>
<policy role="webappsec" />
<policy role="rewrite" />
<policy role="federation" name="SSOCookieProvider" />
</policies>
I now see that the
/usr/hdp/current/knox-server/data/deployments/default.topo.164a4575440/%2F/WEB-INF/gateway.xml
has the following filter order:
<resource>
<role>MYSERVICE</role>
<pattern>/myservice/myapp/</pattern>
<filter>
<role>xforwardedheaders</role>
<name>XForwardedHeaderFilter</name>
<class>org.apache.hadoop.gateway.filter.XForwardedHeaderFilter</class>
</filter>
<filter>
<role>federation</role>
<name>SSOCookieProvider</name>
<class>org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter</class>
<param>
<name>sso.authentication.provider.url</name>
<value>https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html</value>
</param>
</filter>
<filter>
<role>rewrite</role>
<name>url-rewrite</name>
<class>org.apache.hadoop.gateway.filter.rewrite.api.UrlRewriteServletFilter</class>
<param>
<name>service.role</name>
<value>MYSERVICE</value>
</param>
</filter>
My requests are now being properly routed to the knox SSO UI with the correct
originalUrl query param. Something still isn’t quite right though because I’m
stuck in a loop of signing in, I will debug that some more and figure out what
the new issue is.
My question to you is, was it intended for ordering of policies to matter? Is
this something that should be documented (if not already)?
Regards,
Christopher Jackson
> On Jul 16, 2018, at 4:42 PM, Christopher Jackson
> <jackson.christopher....@gmail.com> wrote:
>
> Hey Larry,
>
> After some more debugging I was able to gather the following logs that show
> my problem:
>
> 2018-07-16 11:02:13,622 DEBUG hadoop.gateway
> (GatewayFilter.java:doFilter(116)) - Received request: GET /myservice/myapp/
> 2018-07-16 11:02:13,625 DEBUG webapp.WebAppClassLoader
> (WebAppClassLoader.java:loadClass(459)) - loaded class
> org.apache.hadoop.gateway.filter.XForwardedHeaderFilter from
> java.net.URLClassLoader@30f39991
> 2018-07-16 11:02:13,627 DEBUG webapp.WebAppClassLoader
> (WebAppClassLoader.java:loadClass(459)) - loaded class
> org.apache.hadoop.gateway.filter.rewrite.api.UrlRewriteServletFilter from
> java.net.URLClassLoader@30f39991
> 2018-07-16 11:02:13,633 DEBUG webapp.WebAppClassLoader
> (WebAppClassLoader.java:loadClass(459)) - loaded class
> org.apache.hadoop.gateway.provider.federation.jwt.filter.SSOCookieFederationFilter
> from java.net.URLClassLoader@30f39991
> 2018-07-16 11:02:21,809 DEBUG hadoop.gateway
> (UrlRewriteProcessor.java:rewrite(164)) - Rewrote URL:
> https://host.example.com:8443/gateway/default/myservice/myapp/, direction: IN
> via implicit rule: MYSERVICE/myapp/root/inbound to URL:
> https://host.example.com:9443/myapp/
> 2018-07-16 11:02:21,809 DEBUG federation.jwt
> (SSOCookieFederationFilter.java:doFilter(101)) - Sending redirect to:
> https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html?originalUrl=https://host.example.com:9443/myapp/
>
> It’s clear from the above log capture that one of my rewrite rules is causing
> the issue. However when I compare my rules to those of the WEB HDFS UI I’m
> not certain why one works and the other does not. I tested the WEB HDFS UI
> and I see the correct behavior when I request
> https://host.example.com:8443/gateway/default/webhdfs/v1/tmp?op=LISTSTATUS
> I get redirected to
> https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html?originalUrl=https://host.example.com:8443/gateway/default/webhdfs/v1/tmp?op=LISTSTATUS
>
> Logs from that request:
>
> 2018-07-16 11:34:13,076 DEBUG hadoop.gateway
> (GatewayFilter.java:doFilter(116)) - Received request: GET /webhdfs/v1/tmp
> 2018-07-16 11:34:13,077 DEBUG federation.jwt
> (SSOCookieFederationFilter.java:doFilter(101)) - Sending redirect to:
> https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html?originalUrl=https://host.example.com:8443/gateway/default/webhdfs/v1/tmp?op=LISTSTATUS
>
> The rewrite rule that is causing issues is:
>
> <rule dir="IN" name=“MYSERVICE/myapp/root/inbound"
> pattern="*://*:*/**/myservice/myapp/">
> <rewrite template="{$serviceUrl[MYSERVICE]}/myapp/" />
> </rule>
>
> The only other rewrite rule I have is:
>
> <rule dir="IN" name=“MYSERVICE/myapp/inbound"
> pattern="*://*:*/**/myservice/myapp/{**}?{**}">
> <rewrite template="{$serviceUrl[MYSERVICE]}/myapp/{**}?{**}" />
> </rule>
>
> Note my routes are defined as:
>
> <routes>
> <route path=“/myservice/myapp/" />
> <route path="/myservice/myapp/**" />
> </routes>
>
> However HDFS UI has equivalent rule:
>
> <rule dir="IN" name="WEBHDFS/webhdfs/inbound/namenode/root"
> pattern="*://*:*/**/webhdfs/{version}/?{**}">
> <rewrite template="{$serviceUrl[WEBHDFS]}/{version}/?{**}"/>
> </rule>
>
> My question to you is what other rewrite rules or route info may be coming
> into play here that are configured for WEB HDFS UI that I might be missing
> for my service?
>
> Regards,
>
> Christopher Jackson
>
>
>> On Jul 13, 2018, at 12:22 AM, larry mccay <lmc...@apache.org> wrote:
>>
>> Again, Christopher - I verified with HDP sandbox which is 2.6.5 and am
>> seeing expected behavior.
>> SSOCookieProvider is redirecting to KnoxSSO with an originalUrl query param
>> that reflects the gateway URL for webhdfs.
>>
>> I don't know why you are seeing the behavior that you are describing.
>>
>> I am glad that I'm not seeing the issues that you are describing but it is a
>> bit concerning to me that you are.
>> Can you reproduce this in other clusters as well?
>>
>> On Thu, Jul 12, 2018 at 10:57 PM, larry mccay <lmc...@apache.org> wrote:
>> Hi Christopher -
>>
>> Proxying and SSO together may require a rewrite rule.
>> I'll look at what SSO Cookie Provider is doing though.
>> I would expect originalUrl to be the gateway url from there.
>>
>> Thanks,
>>
>> --larry
>>
>> On Thu, Jul 12, 2018, 4:17 PM Christopher Jackson
>> <jackson.christopher....@gmail.com> wrote:
>> Hi Folks,
>>
>> I have configured a service to use the SSOCookieProvider (federation role)
>> and am seeing some odd behavior that I didn’t expect. Looking for
>> clarification if this is behaving normally or not.
>>
>> I am making a request to:
>> https://host.example.com:8443/gateway/default/myservice/myapp/ and am then
>> getting redirected to
>> https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html?originalUrl=https://host.example.com:9443/myapp/
>> where I am prompted for credentials. I am able to login successfully and
>> then am redirected to the value of the originalUrl query parameter.
>>
>> Essentially what I am seeing is that knox sso is listing the originalUrl as
>> the actual path to the web application instead of the gated value of the web
>> application. For my scenario I would expect that query parameter to contain
>> the value https://host.example.com:8443/gateway/default/myservice/myapp/
>>
>> Why does knox sso behave in this manner? Is this expected? If so, do I need
>> to write additional rewrite rules for this to behave like I would like?
>>
>> Note: If I call
>> https://host.example.com:8443/gateway/knoxsso/knoxauth/login.html?originalUrl=https://host.example.com:8443/gateway/default/myservice/myapp/
>> directly then knox functions as I would expect it to. IE. I can log in and
>> get redirected to my app in the gated path.
>>
>> I am using HDP version 2.6.2.0 with Knox 0.12.0
>>
>> Thanks in advance,
>>
>> Christopher Jackson
>>
>
