Hi Jeremie, To add to Larry¹s thoughts on his point number 1, I have started looking at https://issues.apache.org/jira/browse/KNOX-669. In proxying the UI for Ambari, Knox will ideally not authenticate on behalf of Ambari but let the basic auth occur between the client (browser) and the Ambari server.
I think this is similar to what you are trying to get at and hopefully we can work together and solve both our issues. To get started please look at the service definition xml files if you haven¹t already (found under the install-directory/data/services). You are able to plug in a custom dispatch in there which is what you need in this case. The reason for a custom dispatch would be that the default dispatch blocks certain headers that you need. You can find this in the code snippets around excluding response headers in org.apache.hadoop.gateway.dispatch.DefaultDispatch. You are also able to plug in different providers and you will need to either leave out the authentication provider or more likely write a custom one that does some psuedo authentication for you. There was some recent discussion about the service level configuration for this here https://issues.apache.org/jira/browse/KNOX-671. But as a first step I would start with a custom dispatch and see if you can get your headers flowing back the way you want them. Please keep us in the loop as we are interested in the use case and I¹m certainly also going to go through similar steps. HTH, Sumit On 2/12/16, 10:20 AM, "larry mccay" <[email protected]> wrote: >Hi Jeremie - > >Thank you for reaching with this usecase. > >I have been considering similar patterns recently and came to the >following >conclusion - let know what you think and which you think would best meet >your needs. > >There are a couple different patterns that could be desirable to a custom >service behind Knox: > >1. The authentication of the end user needs to be done by the service >itself, against whatever userstore or mechanism it desires. Knox doesn't >need to issue requests on behalf of the end user but just route requests >from the outside and preserve incoming headers, etc for the service to >deal >with. In this scenario, it doesn't much matter who calls the custom >service >with the required credentials as long as they are presented. >2. The authentication of the enduser should be enforced by Knox and all >requests to the custom service will assert the authenticated identity for >the custom service to accept through a header - much like the Header Based >PreAuth provider for authentication but on the dispatch side instead. This >requires some trust relationship between Knox as a proxy that makes >requests on behalf of other users and the custom service. Without this >trust relationship anyone could assert the identity of anyone else and it >be accepted. > >In the case of #1, I'm not sure that authenticating at the gateway against >LDAP should even be required. If it is going to be done at the service >itself anyway. > >In the case of #2, we would have to ensure that only trusted parties like >a >trusted proxy like Knox can make calls to the custom service. We could use >mutual authentication using SSL between the two. We could use a JWT token >that can be cryptographically verified by the receiver to ensure that it >was issued by a trusted party, etc. > >What are your thoughts on the above and would your usecase fit properly >into one of those options? > >thanks! > >--larry > >On Fri, Feb 12, 2016 at 5:16 AM, Jérémie Gomez <[email protected]> wrote: > >> Hello everyone ! >> >> I am trying to write a custom service which uses LDAP to authenticate >>and >> relays the "Authorization" header so that my end API (behind knox) >>receives >> this header and can perform HTTP Basic Authentication. >> >> I have no problem with authenticating Knox with my LDAP server, but I >> realized that it does not relay the Authorization header to my end API. >> >> I have tried many things but I cannot figure out how to do this. With >> headers rewriting ? With a custom dispatch class ? I have also come >>across >> a class *BasicAuthChallengeFilter.java* in the source code, but I don't >> know if it does the job and how to really use it. >> >> Thanks a lot for your help ! >> >> Jeremie >>
