Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auth-based, per-request permissions system #67

Closed
gavin-norman-sociomantic opened this issue Jul 17, 2017 · 5 comments
Closed

Auth-based, per-request permissions system #67

gavin-norman-sociomantic opened this issue Jul 17, 2017 · 5 comments

Comments

@gavin-norman-sociomantic

Now we have a proper system of authenticating clients, it would be possible to add a permissions system, such that certain requests may only be initiated by certain clients.

An example of this would be very destructive operation like a request which deletes a whole storage channel, which the average client has no place performing.

@gavin-norman-sociomantic
Copy link
Author

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.

@gavin-norman-sociomantic
Copy link
Author

gavin-norman-sociomantic commented Nov 6, 2017

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.

@gavin-norman-sociomantic
Copy link
Author

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.

@gavin-norman-sociomantic
Copy link
Author

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

This would be a major breaking change, though :D

@gavin-norman-sociomantic
Copy link
Author

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant