You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@knox.apache.org by Christopher Jackson <ja...@gmail.com> on 2018/02/26 22:48:45 UTC
Knox SSO JWT consumption in WebSphere Liberty.
Hi All,
I have some questions around the Knox SSO provider.
I have configured my Knox instance for Knox SSO and everything seems to be working. I’m observing the following:
- I make a request to a service behind the gateway
- I get redirected to the Knox SSO form based login page.
- I provide my credentials and click Sign In.
- I am successfully authenticated and a cookie named hadoop-jwt is created.
- I get redirected to my originally requested URL.
I have also configured my Knox instance with a custom provider which uses a HttpServletRequestWrapper to override the getHeaderName and getHeader methods. “AUTH_HEADER” is added to the getHeaderNames enumeration. When getHeader is called for “AUTH_HEADER” it returns a value of “Bearer <jwt_serialized_string>”. I get the JWT serialized string by reading the hadoop-jwt cookie.
Why am I doing this? This is necessary for the authentication mechanism in the container (WebSphere Liberty Profile (WLP)) serving our web application to consume the Knox issued JWT.
The problem I am having is that it seems a later filter (I believe DefaultDispatch) in the chain is over writing the value of the header. As the final request that is made to the original requested URL has an “Authorization” header of the basic64 encoded username and password combination that I provided to the Knox SSO form based login page.
Unfortunately WLP does not currently allow me to configure reading the JWT from a cookie. So I need to handle it in Knox before the request is made to WLP.
Any suggestions on what I may try to overcome this issue?
Regards,
Christopher Jackson
Re: Knox SSO JWT consumption in WebSphere Liberty.
Posted by Christopher Jackson <ja...@gmail.com>.
Hi Larry,
I truly want to set the ‘Authorization’ header, so disregard the ‘AUTH_HEADER’ mention below.
I think I see the issue. It appears that it is DefaultDispatch which is preventing this from working. AbstractGatewayDispatch has a list of exclude headers and ‘Authorization’ is in that list. This is preventing my HttpServletRequestWrapper from injecting the ‘ Authorization’ header value I would like.
Link to relevant code base: https://github.com/apache/knox/blob/92e2ec59a5940a9e7c67ec5cd29044f811dee40a/gateway-spi/src/main/java/org/apache/knox/gateway/dispatch/AbstractGatewayDispatch.java#L133 <https://github.com/apache/knox/blob/92e2ec59a5940a9e7c67ec5cd29044f811dee40a/gateway-spi/src/main/java/org/apache/knox/gateway/dispatch/AbstractGatewayDispatch.java#L133>
Still looking for suggestions on how I may be able to achieve this, any thoughts?
Regards,
Christopher Jackson
> On Feb 26, 2018, at 8:12 PM, larry mccay <lm...@apache.org> wrote:
>
> Hi Christopher -
>
> That sounds very strange is the AUTH_HEADER a standard header that I am unaware of?
> I will try and reproduce this.
>
> thanks,
>
> --larry
>
> On Mon, Feb 26, 2018 at 5:48 PM, Christopher Jackson <jackson.christopher.lee@gmail.com <ma...@gmail.com>> wrote:
> Hi All,
>
> I have some questions around the Knox SSO provider.
>
> I have configured my Knox instance for Knox SSO and everything seems to be working. I’m observing the following:
>
> - I make a request to a service behind the gateway
> - I get redirected to the Knox SSO form based login page.
> - I provide my credentials and click Sign In.
> - I am successfully authenticated and a cookie named hadoop-jwt is created.
> - I get redirected to my originally requested URL.
>
> I have also configured my Knox instance with a custom provider which uses a HttpServletRequestWrapper to override the getHeaderName and getHeader methods. “AUTH_HEADER” is added to the getHeaderNames enumeration. When getHeader is called for “AUTH_HEADER” it returns a value of “Bearer <jwt_serialized_string>”. I get the JWT serialized string by reading the hadoop-jwt cookie.
>
> Why am I doing this? This is necessary for the authentication mechanism in the container (WebSphere Liberty Profile (WLP)) serving our web application to consume the Knox issued JWT.
>
> The problem I am having is that it seems a later filter (I believe DefaultDispatch) in the chain is over writing the value of the header. As the final request that is made to the original requested URL has an “Authorization” header of the basic64 encoded username and password combination that I provided to the Knox SSO form based login page.
>
> Unfortunately WLP does not currently allow me to configure reading the JWT from a cookie. So I need to handle it in Knox before the request is made to WLP.
>
> Any suggestions on what I may try to overcome this issue?
>
> Regards,
> Christopher Jackson
>
Re: Knox SSO JWT consumption in WebSphere Liberty.
Posted by larry mccay <lm...@apache.org>.
Hi Christopher -
That sounds very strange is the AUTH_HEADER a standard header that I am
unaware of?
I will try and reproduce this.
thanks,
--larry
On Mon, Feb 26, 2018 at 5:48 PM, Christopher Jackson <
jackson.christopher.lee@gmail.com> wrote:
> Hi All,
>
> I have some questions around the Knox SSO provider.
>
> I have configured my Knox instance for Knox SSO and everything seems to be
> working. I’m observing the following:
>
> - I make a request to a service behind the gateway
> - I get redirected to the Knox SSO form based login page.
> - I provide my credentials and click Sign In.
> - I am successfully authenticated and a cookie named hadoop-jwt is created.
> - I get redirected to my originally requested URL.
>
> I have also configured my Knox instance with a custom provider which uses
> a HttpServletRequestWrapper to override the getHeaderName and getHeader
> methods. “AUTH_HEADER” is added to the getHeaderNames enumeration. When
> getHeader is called for “AUTH_HEADER” it returns a value of “Bearer
> <jwt_serialized_string>”. I get the JWT serialized string by reading the
> hadoop-jwt cookie.
>
> Why am I doing this? This is necessary for the authentication mechanism
> in the container (WebSphere Liberty Profile (WLP)) serving our web
> application to consume the Knox issued JWT.
>
> The problem I am having is that it seems a later filter (I believe
> DefaultDispatch) in the chain is over writing the value of the header. As
> the final request that is made to the original requested URL has
> an “Authorization” header of the basic64 encoded username and password
> combination that I provided to the Knox SSO form based login page.
>
> Unfortunately WLP does not currently allow me to configure reading the JWT
> from a cookie. So I need to handle it in Knox before the request is made to
> WLP.
>
> Any suggestions on what I may try to overcome this issue?
>
> Regards,
> Christopher Jackson
>