Interesting... So, I assume that you added the filter as an identity-assertion provider or something in the provider chain?
If you are using the default dispatcher then the authenticated user should be asserted to you already by the gateway as a user.name or doas query parameter. When the hadoop cluster is not kerberized you will get user.name and when it is you will get doas. Now you are probably getting it as a query parameter as well as the custom header that you added. Which is fine but your service will require that specific provider configured for the entire topology and if there is some other need for another identity-assertion provider then you will need to adjust to multiple topologies or something like that. This makes me wonder whether a new dispatch would allow configuration at the service level that indicated a query param or header name to assert the identity within. Any such mechanism needs to take into account the possibility of a MITM attack between the gateway and the service/app. SSL should be used at a minimum and SPNEGO should be used in secure clusters. FYI - If you were to use the hadoop-auth module for authentication at the REST service then that would by you SPNEGO and delegation token support - as well as other handlers such as JWT for SSO in your web app. This would also buy you the user.name and doas query parameter support. On Mon, Nov 9, 2015 at 11:06 AM, Christopher Jackson < [email protected]> wrote: > Hi Larry, > > I have a rest services and a web application sitting behind the Knox > Gateway. It’s important that the rest services know what user was > authenticated for each request so it can do some audit logging in the > services layer. Additional I want to display the logged in username in the > web application. > > To achieve this I created a filter that adds the user info into the > header. > > Is there some better way to achieve this that you have seen in the field? > > Regards, > Christopher Jackson > > On Nov 8, 2015, at 9:51 AM, larry mccay <[email protected]> wrote: > > Hi Christopher - > > I was just going to point you to the providers for adding filters. > I'm curious what sort of filter that you wanted to add and whether it fits > in the existing provider types. > > It is relatively straight forward to add a new authentication or > federation filter or one of the others but defining a new type (role) of > provider requires a bit more work than it ideally should. > > thanks! > > --larry > > On Sun, Nov 8, 2015 at 12:05 AM, Christopher Jackson < > [email protected]> wrote: > >> I was able to achieve what I wanted by doing the following: >> >> 1) Defining a new provider which contributes the filter I require >> 2) Setting a policy for my custom service to use that provider. >> >> This approach seems to be sufficient, disregard my prior question. >> >> Regards, >> Christopher Jackson >> >> > On Nov 7, 2015, at 8:38 PM, Christopher Jackson < >> [email protected]> wrote: >> > >> > Hi, >> > >> > What is the proper way to add a filter to a custom gateway service? I >> know I can extend ServiceDeploymentContributorBase to add a filter. But I >> thought with Knox 0.6.0 and its new declarative approach (rewrite.xml, >> service.xml) that I would be able to do it simply by making additions to >> the service.xml file. After a failed attempt and taking a look at the >> ServiceDefinition class I see that only routes, policies, and a custom >> dispatch can be declared in it, why not filters? >> > >> > Regards, >> > >> > Christopher Jackson >> >> > >
