This topic was ALMOST what I was looking for but it fell just short
The example describes how to authN the client using the HTTP headers in the WS handshake but it doesn’t provide a means to pass these up to the application that gets the ReactiveSocket instance and begins interacting with the remote entity.
As a result, even though the application can be sure the remote party was authenticated they don’t know WHO the remote party is.
I logged an issue against the rsocket-js implementation along similar lines:
So, although this is not a “protocol” issue per se, it would be useful to hear from the architects if the transport abstraction intentionally excludes authN or if this is just how the implementations work today.
Ideally I’d like, when running an RSocket Server, to have a hook that I can use to:
- intercept the incoming transport layer connection (WS or TCP)
- AuthN the client (could use TLS when transport is TCP?), and
- reject the connection if AuthN fails, OR,
- attach some data to the ReactiveSocket that identifies the client so this is available to application which might perform AuthZ or have some business logic tied to the identity of the client.
In Java, this might be something like
java.security.Principal which I think is already well integrated into how Spring does AuthN and AuthZ for WebSockets.