NATS Streaming Client Authorization

[ramasa]

trafficstars

Pub/Sub permission is working only on Nats topic and not on NATS Streaming topics. This is a blocker for us to restrict our clients to specific topic

[kozlovic]

@ramasa Yes, we need to have a better story for authentication/authorization in NATS Streaming. In the meantime, do you need to block producers only or subscribers too? If only producers, you may have a way to prevent sending to specific channel because the underlying subjects for streaming publish subject would allow that. However, it will not be possible for subscriptions since clients sends subscriptions requests to a single internal subject.

[ramasa]

Trying to migrate our clients from REST to NATS. Using JSON-RPC 2.0 over NATS request/response for majority of the use case and #192 solved security issue. Thought of using NATS Streaming for async updates to clients instead of REST polling. So for now the only streaming use case is clients as subscribers.

[kozlovic]

@ramasa Thanks. We need to add some form of authentication/authorization at the NATS Streaming level since one cannot fully leverage the provided low level NATS ones.

[Quentin-M]

Hi,

We also are pretty surprised that NATS has a strong authorization mechanism, but NATS Streaming does not whatsoever. Do you have any plans?

[kozlovic]

Not whatsoever. You can use NATS authentication and authorization, except for subscriptions. But will will add something in the near future. I don't have an ETA though.

[julienvincent]

Hi @kozlovic is there any update on this? I would really like to be able to restrict subscriptions and publishers with nats streaming

[kozlovic]

@julienvincent Still no ETA at the moment unfortunately.

[ihippik]

Tell me why, when I connect with the correct name and password I get a stan error: connect request timeout?

[kozlovic]

@ihippik Could you give more details? How do you start the server and what do options do you use to connect? A "connect request timeout" is generally more indicative of using the wrong cluster name for instance, or the streaming server not reachable (you would get NATS connectivity, but the request does not reach the streaming server).

[ihippik]

He was not attentive. Connected with another claster-id. Thanks for the answer.

[vanya2143]

@kozlovic Hi, is there any update on this? or alternative settings to deny to subscribe _INBOX.> . Maybe Leaf nodes can resolve this problem ? Thanks for your attention

[kozlovic]

@vanya2143 Streaming server and clients must be able to subscribe/publish on _INBOX.> since they are used to communicate. You can use leaf nodes to isolate a streaming server and its clients from the rest of the traffic on the same NATS cluster if you want, but for the streaming server/client account, you need permissions on _INBOX.>

[costa]

@ramasa or anyone, did you find a feasible workaround? or abandoned nats-streaming altogether?

[ramasa]

@costa Built something around this

Internal Sender -> NATS Streaming ->App

App

 Generate sequence
 Store in a DB(MongoDB)
 Publish to receiver via NATS on topic.sequence

External Receiver - Detect missing sequence if any and ask for it

[costa]

@ramasa Thank you, well you've effectively rolled your own streaming of sorts... Got me thinking in all directions, I might choose another message broker altogether, I need some sort of user permissions management, so if I have to write it myself, another platform might provide a better framework.

[kozlovic]

@costa Not sure if you are aware, but we are working on another streaming product, called JetStream that is core of the NATS Server and therefore is accessed through normal NATS clients. This solves the client auth/account isolation issues that NATS Streaming suffers from. The product is currently in tech preview. Here is the branch you can look at if you wish: https://github.com/nats-io/nats-server/tree/jetstream

[ripienaar]

Full guide to JetStream can be found here https://github.com/nats-io/jetstream/blob/master/README.md

[costa]

Thank you guys, and I wish you the best of luck with the new project, I will be sure to check it in a few months, but at the moment, with my current project, I can't afford the (very) early adoption.

My use case involves multiple clients each subscribing to its own single channel, and my current solution (after discovering the user auth problem) is a custom bridge component that runs on the NATS side, subscribes to channels for users and re-sends the messages to the other side using ZeroMQ, with actual authentication done by ssh (with server&client key pairs) which also provides secure tunnels for the setup above.