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 < [email protected]> 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 >
