Websocket Server authentication

[diogob]

Hi there, I was wondering if you consider server authentication and authorization as part of the project scope. I am about to start working on a project to add an authentication layer but in case you already have thoughts for this feature I would love to discuss the feature design for a potential future code contribution.

[agentm]

Hi @diogob, this would indeed be a valuable contribution! I have put some minimal thought into the considerations needed for an authentication system, so I'll try to scrape them together here for discussion:

• ideally, both the Haskell RPC and Websocket servers would share the same user/password database
• ideally, both the Haskell RPC and Websocket servers would share the same user/password authentication schemes
• Project:M36 does not support per-table, user-specific granular permissions, so multiple users will all see the same relation variables and other state
• we should never pass around password in-the-clear
• does the auth protocol support multiple authentication schemes (TLS certificates? OAUTH? useful for future-proofing)
• is the auth protocol based on some standard?
• we should serialize the user along with the other metadata in the transaction graph for auditing purposes (but how should this metadata be presented to the user?)

[agentm]

What do you think? What sort of authentication did you have in mind?

[diogob]

Thanks @agentm these notes already gave me a good starting point.
I thought of using private-public key pairs to enable an authentication protocol similar to webauthn. One of the main advantages is that no password is ever stored on the server and a signature could be sent with each message (so no TLS is needed to ensure authenticated messages although there is the additional cost of signing). I have a proof of concept on this project.

However, I'm aware that rolling out a custom authentication protocol might be reckless. Having said that we could start with something simpler, such as the scram-sha-256 used by PostgreSQL, but in this case we would need to have TLS connections.

Please let me know what are your thoughts on these 2 options.

[agentm]

Hm, does WebAuthn only work from within a web browser? I did some googling on it but don't fully understand the architecture.

It would be nice to support the Haskell RPC library with whatever solution you propose, but I suppose it's not a hard requirement. Since the Haskell RPC layer is already totally custom, it's open to any sort of authentication strategy including TLS certificates or signatures.

I'm not sure what's easiest to implement here...

[diogob]

WebAuthn's specification looks very browser-centric, since the list of dependencies includes HTML and DOM. It is also very centered around the idea of human users (as opposed to authenticating other systems). I'll play around with the code a bit to get acquainted with it and come back when I have a better understanding of those parts of the existing code base.

[boogerlad]

Project:M36 does not support per-table, user-specific granular permissions, so multiple users will all see the same relation variables and other state

Should it? A lot of companies don't use the user / per row / table permissions in Postgres, and instead reimplement it as part of the backend layer. I'm happy to be proven wrong though. If Project:M36 supported such a system and it could encompass all use cases while not being too cumbersome to work with, the backend layer could be eliminated entirely.