Hello Tomasz,

I did a small test, I sent a request to Knox using the wscat client with
the command you listed 'wscat -n --auth test:password  -c
wss://localhost:8443/gateway/sandbox/echows/'
As I suspected it gets added as a "Authorization" header with value "Basic
YWRtaW46YWRtaW4tcGFzc3dvcmQ=". As of now Knox ignores this header but you
could use it at the backend websocket server to authenticate the client and
then decide to open or close the connection - just another way to
authenticate. This should also work with your TypeScript client.

This does put the burden of authentication on the backend server though
which is a downside.

Best,
Sandeep







On Fri, Oct 13, 2017 at 9:44 AM, Tomasz Uliński <
[email protected]> wrote:

> Hello Sandeep,
>
> Thank you for your quick response. In the meantime I supplemented my
> knowledge a bit regarding to web security as it's not my main area of
> expertise.
> Let me first refer to your points:
>
> > 1. Are there are any clients out there which support Basic Auth for
> > Websocket ? from my brief search I could not find any.
> For testing websocket services in Knox I use a tool called *wscat*:
> wscat -c wss://knox-server/gateway/default/echo
> It enables to pass Basic Auth credentials as follows:
> wscat --auth <username:password> -c wss://knox-server/gateway/default/echo
>
> In our web app (TypeScript) we create a client in the following way:
> const client = Stomp.over(new WebSocket(this._url));
> client.connect(
>    {login: '<login>', passcode: '<passwd>'},
>    this.handleConnected(client),
>    this.handleError(client)
>  );
>
> Regarding to your answers to my initial questions:
> 1. Ok, I'll try to add websocket authentication to 0.14.0
> 4. It's quite critical for us to have secured websocket connections in
> Knox. That's why I asked for some recommendation in terms of using patched
> Knox until our changes will be released officially. I will ask this
> question to Ambari guys.
> 5. Thanks for pointing me the exact place in the project.
>
> Follow-up questions:
> 6. In HDP docs (
> https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.2/
> bk_security/content/authentication_providers.html)
> I found that there is sth like Anonymous Authentication Provider in Knox
> "Used by Knox to let the proxied service or UI do its own authentication."
> Wouldn't that be the easiest solution for our case. I mean passing
> Authorization header by Knox to our backend service? I created a custom
> topology with this kind of auth provider, but Authorization header is still
> missing while Knox sends websocket handshake request to our backend
> service.
> 7. I saw that there is a closed KNOX-710 issue in jira related to handling
> Zeppelin's websockets. As I understand endpoints exposed this way lack
> authentication, right?
> 8. Our initial idea was to use Basic Auth over https, because it's a
> default setup of Knox (BASIC authentication against an LDAP store), but
> maybe we should think about sth more sophisticated? Nevertheless I am of
> the opinion that while Basic Auth is the default for https calls it should
> be the same for websockets, do you agree?
>
> Best,
> Tomasz
>
> On Wed, Oct 11, 2017 at 8:13 PM, Sandeep More <[email protected]>
> wrote:
>
> > Hello Tomasz,
> >
> > Thanks for your interest with this ! While working on KNOX-895
> > <https://issues.apache.org/jira/browse/KNOX-895> I have been thinking
> > about
> > this, as a result of which I have been asking myself few questions:
> >
> > 1. Are there are any clients out there which support Basic Auth for
> > Websocket ? from my brief search I could not find any.
> > 2. The specs <https://tools.ietf.org/html/rfc6455#section-10.5> do
> mention
> > that one could use HTTP Auth, if we do this we need to make sure we do
> not
> > break other existing services.
> > 3. For now, when a WS request is made, Knox's Websocket handler is
> invoked
> > skipping the security framework (servlet based), this part needs to be
> > revisited to make sure there is no duplication of code.
> > 4. Some of the things, such as policies, makes sense for HTTP but not for
> > WebSocket how do we pick and choose these things.
> >
> > These are some of the questions to think about. Following are the answers
> > to your question
> >
> > 1. IMO this should go in 0.14.0 / 1.0.0
> > 2. Are you wanting to backport this to 0.12.0 ? If you are looking to
> port
> > it back in an HDP release, you might want to open a ticket with HDP
> folks.
> > 3. You might want to take this up to the HDP folks, once you have a patch
> > out, we can get it reviewed, tested and put it in 0.14.0 / 1.0.0
> > 4.  I am sorry but I did not understand the question, do you wish to add
> > this new change to Knox or you want to fork Knox and install a separate
> > fork. I am not sure how Ambari manages separate versions but I presume
> > there is a way to do that, may be someone knowledgeable in Ambari  can
> > answer this question.
> > 5. Sure, you can start with gateway-server module, look for
> > "org.apache.hadoop.gateway.websockets" package.
> >
> > Best,
> > Sandeep
> >
> >
> >
> > On Wed, Oct 11, 2017 at 11:55 AM, Tomasz Uliński <
> > [email protected]> wrote:
> >
> > > Hello,
> > >
> > > I'd like to fork Knox and add authentication functionality for
> websocket
> > > connections.
> > > Here is a StackOverflow question (
> > > https://stackoverflow.com/q/46589806/4177726) describing what I'd like
> > to
> > > achieve.
> > > We use Knox 0.12.0 from HDP 2.6.2.0-205.
> > >
> > > I have following questions:
> > > 1. Which version should we enhance with websocket authentication
> > > functionality in order to use it along with other HDP 2.6.2 components?
> > We
> > > want to fork a stable version, but we are wondering whether we should
> > stick
> > > with 0.12.0 or move to 0.13.0.
> > > 2. How fast can it happen to merge our changes to official version of
> > Knox
> > > (e.g. to release it as 0.12.1)?
> > > 3. How fast it could be included into HDP release (e.g. 2.6.3)?
> > > 4. What way of deployment of our enhanced Knox version you'd recommend
> > > before our changes will be accepted and released? Is it possible to
> force
> > > Ambari to manage different version of the particular component (in our
> > case
> > > Knox version built on our own)?
> > > 5. I cloned Knox git repo. In which module I should make changes to add
> > > websocket auth functionality? Any advice related to particular classes
> > will
> > > be very helpful for me.
> > >
> > > Looking forward for your recommendations.
> > > Best,
> > > Tomasz Ulinski
> > >
> >
>

Reply via email to