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

Access control of keys? #40

Closed
sjames opened this issue Sep 9, 2020 · 11 comments
Closed

Access control of keys? #40

sjames opened this issue Sep 9, 2020 · 11 comments
Labels
new feature Something new is needed

Comments

@sjames
Copy link

sjames commented Sep 9, 2020

Hi,
Is it possible to have access control to keys? An ability to control the visibility and write access may be useful in some scenarios.

Regards,
Sojan

@JEnoch
Copy link
Member

JEnoch commented Sep 9, 2020

Hi @sjames ,
This feature is indeed on our roadmap, but not yet implemented.

@luca-della-vedova
Copy link

Hi @JEnoch!

Thought I would check in to see if there is any update on this (i.e. in which months it might be tackled)?

@JEnoch
Copy link
Member

JEnoch commented Jun 15, 2021

Hi @luca-della-vedova,

This is still on our roadmap, but not for short term (i.e. at least not for the next 3 months).
We are still thinking about the options we may have for this. But they also depend on use cases:

  • on which authentication mechanism do we base access control ? (X.509 certificates? user/pass? other?)
  • do we need access control in also in peer-to-peer, or only made by the zenoh routers ?
  • can we assume that the zenoh routers are trusted, or shall we take (more complex) measures to prevent a "rogue router" that would not apply access control correctly ?
  • or shall we have a totally different approach as suggested in Topic key Authorization and Encryption #97 ?

What would be your use case and your desired deadline for this feature ?

@sjames
Copy link
Author

sjames commented Sep 20, 2021

Hi @JEnoch

I think you should start discussing the security concepts while the protocol is evolving rather than having to change something later on due to security. If there is one issue that may prevent me from deploying Zenoh on a product today, it is security. This may not be an issue when working on a private network, but still the implementation and more importantly, the spec seems incomplete without security.

If I may, I'll try to write my thoughts on the points you raised.

  1. Authentication mechanism: Since this is a distributed, no broker mechanism, asymmetric keys would be a natural fit. This is already well defined and would make sense to stick to standard protocols and algorithms. JWT does this without having to store anything on the router.
  2. I expect that there will be different levels of mechanisms needed simultaneously. I can think of a use-case where peers must authenticate each other. I read that the clients authenticate the routers in the current implementation. The reverse must also be possible - routers must only allow authentic clients.

Regards,
Sojan

@Mallets Mallets added the new feature Something new is needed label Feb 15, 2022
@Mallets Mallets moved this to Q4 2022 - Oct-Dec in Zenoh Roadmap Apr 4, 2022
@Mallets Mallets removed this from Zenoh Roadmap Apr 6, 2022
@Charles-Schleich
Copy link
Member

Charles-Schleich commented Dec 4, 2023

I believe this is related to issue eclipse-zenoh/roadmap#8 on the Roadmap.
Posted here for tracking.

@stevenlovegrove
Copy link

I noticed eclipse-zenoh/roadmap#8 was closed as completed but there is no referenced diff and I'm guessing perhaps it has been pushed back?

Assuming that it isn't implemented already, does anyone know if the plugin system would be capable of allowing implementation of some simple ACL for subtrees in routers, based perhaps on authenticated username?

@Mallets
Copy link
Member

Mallets commented May 27, 2024

Support for ACL on key-expression from configuration has been added in 0.11.0-rc.1.

@stevenlovegrove
Copy link

@Mallets really exciting! Looking through the diff, it isn't clear if this is only for interfaces right now, or whether it can also be configured based on client / peer authentication?

@Mallets
Copy link
Member

Mallets commented Jun 13, 2024

At the moment it is only per interface

@Mallets
Copy link
Member

Mallets commented Jun 14, 2024

Support for TLS certificates and user/password is being added in #1073

@oteffahi
Copy link
Contributor

Added as the current ACL feature

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature Something new is needed
Projects
None yet
Development

No branches or pull requests

9 participants