AuthZ/permissions -- restrict data access to tree namespace user or device is in

[cbrake]

right now, any user or device can access any point data in the system. Would be nice to if a user/device could only access data for the segment of the tree they are in.

[cbrake]

NATS Leaf nodes may be applicable. However, it is not clear if leaf/nodes accounts have a completely separate subject namespace, or if a leaf node/account can access a portion of the subject namespace.

[cbrake]

NATS accounts gives you true multi-tenancy, where everything is isolated. Users can have permission maps that restrict a user to specific subject space. It seems we want simple users, not accounts.

[cbrake]

Node topology looks something like this:

thinking of arranging the subjects by node IDs: /rootID/dev1ID/A

on device #1, if I publish to /dev1ID/A, this would automatically be mapped to /rootID/dev1ID/A when the message is published upstream

devices may be located anywhere in the tree, ex: /rootID/group1/group2/dev3ID

so user /rootID/group1/group2/user1 would have access to /rootID/group1/group2/> subjects, so could access dev3ID's data.

the idea is devices or users can access parent node and all sibling nodes/descendants.

[cbrake]

NATS accounts allows remapping using from/to:

https://docs.nats.io/nats-server/configuration/securing_nats/accounts#import-configuration-map

Seems like that has potential.

[cbrake]

seems just plan users/authz makes sense for initial implementation:

https://docs.nats.io/nats-server/configuration/securing_nats/authorization

accounts/leaf nodes seems too complex for this application where the NATS api is relatively small, so manually prefixing upstream traffic is not a big deal.

[cbrake]

Apparently the restriction of using not using wildcards in mapping account services has been lifted in recent versions of nats-server, from slack:

https://natsio.slack.com/archives/C069GSYFP/p1632331335086300

Will need to think about this some more ...

[cbrake]

correct, the current UI simply fetches and displays the nodes and trees the user is child of, but there is nothing to prevent the frontend from fetching all nodes. So we only display what the user has access to, but don't prevent him from accessing everything. Works for now as I focus on features, but is not production grade.

[cbrake]

Very interesting projects -- amazing all the stuff out there.

For devices, we don't have to wrap NATS -- they currently speak native NATs.

It seems we must do auth at the NATs level. Devices will subscribe/post to a NATS topic:

root.group1.device1

If device had NATS access to root, then it could subscribe/post to root.group2.

Adding an auth mechanism on top of NATs (would require wrapping NATs) would be possible, but then we loose most of the benefits of using NATS in the first place:

• Synadia NGS
• clients already exist in most langages
• a single model for communicating with the system (NATS)
• users now need to familiar with multiple technologies
• Jetstream -- how does a wrapper handle all this?
• syncronization -- if we add more types/mechanisms, then we also need to sync these new types of data.

I'm trying to avoid another mechanism for configuring Auth -- I want the location in the node tree to specify permissions explicitly. This saves a ton of overhead and complexity as a programmer and user.

That all said, my use case (very distributed systems) may be different than yours, so I don't want to discourage experimentation. A simple node tree may not provide enough dimensions for some use cases.

The approach I've taken with SIOT is to focus on solving real world problems. I still need to write up articles on some of the applications I've implemented using SIOT recently. It is easy for me to get deep in the weeds of implementing cool architectures, but what really helps me pull things forward is solving real world problems. This is why I've not worried about authZ until now -- I did not have a need in the projects I was working on. It might help to share some details on the type of problems you are trying to solve with SIOT. Feel free to email me directly.

Another nagging concern with wrapping NATS is seems we really need to prove the NATS auth model is inadequate first before justifying adding another layer of abstraction and complexity. Lets try to solve the immediate problems we have now and see what does not work.

Again, I don't want to discourage exploration, but I also want to be make sure our visions are aligned. It is easier to sort this out now vs after working together for 6mo and discover we are heading in different directions..

[cbrake]

Another possibility is that each nats client that connects authenticates and is given a random secure message space that it can subscribe/publish to. The server keeps a map of node hierarchy locations and can then map messages to it. If the node is moved around on the server, then this would need to update dynamically, but the client would not have to know anything. Advantage of this is the client does not need to know anything about the server node hierarchy other than its node ID, or user/auth credentials.

This may allow us to bypass the entire NATS auth mechanism.

cc: @bminer

[cbrake]

another scheme might be that a user or device do everything in their own
subject namespace: /a/<node id>/..

Where the remote user/device only has permission to read/write to /a/<node id>/*.

The leading /a stands for authenticated.

Any time a point is received, it travels up the tree. If we encounter users or devices, we re-broadcast the message to the /a/<node id>/... subject for the remote user/device to consume. If nobody is subscribed to the /a/... subjects, this rebroadcast should not cost very much.

One challenge with this is we now have multiple subjects to keep track of, so we need to be sure not to send the message back to the remote client that sent it. Perhaps when we receive a point, we keep track of who it came from and then as we walk up the graph, we never re-transmit back to that device/user.