Custom service with Basic Authentication

[Jérémie Gomez <jg...@octo.com>]

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

Re: Custom service with Basic Authentication

[Sumit Gupta <su...@hortonworks.com>]

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" <lm...@apache.org> 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 <jg...@octo.com> 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
>>

Re: Custom service with Basic Authentication

[larry mccay <lm...@apache.org>]

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 <jg...@octo.com> 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
>