Support privileges-enforcement for jetstream similar/identical to normal nats.

[tpihl]

Feature Request

Support privilege-enforcement for jetstream similar/identical to normal nats.

I can define exactly what subjects a user is allowed to publish or subscribe on in a fairly complete manner for core nats. And I can use that to limit the subject used by a user to publish to a stream (i'e only some of the subjects that the stream listen to (wildcarded or multiple subjects).

However, I cannot limit what information can be read by a user via a consumer. And I need to

Use Case: A specific user is only allowed to read some of the msgs in a stream. Creating a consumer with a filter wider than allowed in permissions should result in a failure. Same with all other interfaces to read from a stream.

Proposed Change: Validate that any subject used to access a stream would be allowed as a direct subscription.

Who Benefits From The Change(s)? Everyone that want to use jetstream with any level of access rights management

Alternative Approaches Solve in code on client side, and thats not possible if we try to use nats jetstream between different organisations or different domains or reasonably anywhere. Maybe this is solved by unneeded leafnodes and bridges instead??

/T

Use Case:

Different users are allowed to publish to a specific subset of a stream. An example is that a specific user(component) is the only one that is allowed to publish info about some specific items (in an example where stream listens for info.item. some user may be allowed to publish on info.item.4 and info.item.9. Another user may publish in any stream about item 14 (.item.14). This works perfect with current permission model.

But I cannot figure out how to the same restriction for information a specific user may read from those streams. It would make sense to make those permissions identical to what we have today (and they work to limit what information a user may see when the the information initially was published to the stream). But it need to limit, in the same way, what msgs may be read through a consumer of that stream by enforcing a matching filter (or by other means first hide any msgs originally posted on subjects that this user cannot subscribe to before applying any consumer filters).

Proposed Change:

evaluate privs vs consumer filters (most similar to the limitation in what you can subscribe on in nats), or hide msgs with subjects not permitted to subscribe to when the consumer actually filters the messages available through the consumer

Who Benefits From The Change(s)?

Ability to use existing functionality also for jetstream consumption of nats messages instead of only for live messages

Alternative Approaches

Solving it on application level removed almost all benefits of the security-enforcement possible in the server.

[tpihl]

Any progress with acl for consumers?

[derekcollison]

We are aware of the discrepancy between security models etc. We have been working on some ideas to help normalize. Under the covers it still will result in the low level understanding of consumers and the subjects they use to interact etc.

FYI for single subject filtered consumers you can lock that down already. The client will use an extended version of consumer create that appends the filter subject to the end of the create subject itself. for instance if I want to create a consumer named DEREK on a stream called TEST, that has a filtered subject of foo.*, the subject the clients will use is $JS.API.CONSUMER.CREATE.TEST.DEREK.foo.*. This can be used for user publish permissions at the core level. Some users/customers who want to be pedantic also put in a deny perm on $JS.API.CONSUMER.CREATE.TEST.DEREK