Pre-shared key

[zsolt777]

Hi @jchristn!

Thank you again for this great library!

Could you tell me please the exact purpose of the pre-shared key? As I can see it is some kind of authentication, as its name implies, right?

• If that is the case then I wonder why is it limited to 16 bytes?
• As I can see currently the server can handle just one PSK/server. At server side it could be a ConcurrentDictionary instead of a string, to allow the server to handle many PSKs simultaneously and safely.

If both of the above would be implemented, then it could be used to authenticate users very easily with JWT tokens, or any other kind of tokens, keys.

...or if at the server side there would be a "custom client PSK validator event" when client sends the PSK, then it would be easy to implement JWT validator, or any other login mechanism.

What do you think?

Thank you!

[jchristn]

Hi @zsolt777 thank you for your kind words!

The preshared key was an early feature meant to provide a really simple control over which nodes were allowed to connect. I didn't take the feature too far because of two reasons: 1) the current implementation sends the key directly over the network (bad idea), and 2) any level of security that could be desired could be added by using SSL/TLS (including client-specific certificates).

If the functionality were to be enhanced, I would definitely love to see the ability to control which key is used for which node, and, a mechanism by which the key is never sent over the wire, but rather, the server would send a challenge and request that the client encrypt it and send the response. I wouldn't use it for encrypting payload data; in fact, I wouldn't be a fan of re-introducing anything that modifies payload data (too much compatibility issues across platforms when using things like GZipStream or SslStream). But, it would be a really simple way of (somewhat) securely authenticating that the other side has the right to connect.

I also like the idea of custom validator.

Out of curiosity, what do you feel would be the advantages/disadvantages of this approach vs using SSL?

[zsolt777]

Good question @jchristn

We use JWT tokens and I was wondering if it was possible to use Watson Server somehow to handle requests with custom validator.

The communication must use TLS, that is not a question. On top of that the authorization is another question.
I think it depends..

If I would like to use the Watson stack for machine only communication, then I would prefer some kind of certificate based authorization, and I agree in this case I would not encrypt the payload, since the communication is already encrypted by TLS.

But sometimes it is hard to let each user/client/node have its own certificate for authorization, and in that case the custom validator would be excellent to implement user/pwd/JWT etc..

[jchristn]

Hi @zsolt777 the challenge with this is that this would essentially require a state machine inside of the DataReceiver on both client and server. I know there is work that needs to be done there anyway within the library, but it's a pretty big lift and I'd rather keep the burden on the application consuming the library to implement a state machine outside of it.... At least, for now.

Marking this as an enhancement; thank you for the suggestion. I'm open to a PR if you'd like to give it a go.

[zsolt777]

Hi @jchristn, I think your previous comment was for #119, and not for this. Anyway, thank you for your efforts!
Cheers

[jchristn]

Hi @zsolt777 - the comment regarding the state machine was related to adding authentication capabilities. Cheers