Auth-based, per-request permissions system about swarm HOT 5 CLOSED

Another aspect which was discussed: it'd be nice to also have permissions based on an ip white/black list. For example, instances of apps running on a test server should not be allowed to read from but not write to live nodes. They will likely user the same auth key as the real apps, but can be distinguished by their ip.

from swarm.

A simple initial idea for client-based permissions:

1. We add support for a set of action categories to be defined by the node. (e.g. "read", "write", "delete".) (These will need to vary by node, as some node types have different concepts of destructive requests, for example.)
2. Each request is assigned to one of these categories. (See https://github.com/sociomantic-tsunami/swarm/blob/v4.x.x/src/swarm/neo/node/ConnectionHandler.d#L65.)
3. The node's credentials file (or some config file) is extended to also allow specifying whether each client is allowed/disallowed to perform each action. (It may make sense to have the default permission always be "disallow", unless configured otherwise.)
4. When a client sends a request to a node, the node can look up the action category of the request and the permissions of the client, then decide whether to continue handling the request or return some error code.

from swarm.

Another aspect which was discussed: it'd be nice to also have permissions based on an ip white/black list. For example, instances of apps running on a test server should not be allowed to read from but not write to live nodes. They will likely user the same auth key as the real apps, but can be distinguished by their ip.

I think this is a separate idea. I don't think the implementation would share much in common with the per-client / per-request permissions. Split to #166.

from swarm.

It may make sense to have the default permission always be "disallow", unless configured otherwise.

This would be a major breaking change, though :D

from swarm.

After some discussion, we decided to go for a super simple scheme, as follows:

• #169 enables request handlers in the node to get the name of the connected client.
• For very sensitive requests (e.g. RemoveChannel, Redistribute), we add a simple check that the client's name is "admin" and send an error status code, if not.

This approach addresses all of our current needs. We can extend it to a more complicated system, if we ever need one.

Nothing more to do here.

from swarm.