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

Support for authentication #244

Open
soupdiver opened this issue Dec 18, 2017 · 5 comments
Open

Support for authentication #244

soupdiver opened this issue Dec 18, 2017 · 5 comments

Comments

@soupdiver
Copy link

I currently try to implement the "Ironhouse pattern" mentioned here.
The example C code

    //  Start the authenticator and tell it do authenticate clients
    //  via the certificates stored in the .curve directory.
    zauth_t *auth = zauth_new (ctx);
    assert (auth);
    zauth_set_verbose (auth, true);
    zauth_allow (auth, "127.0.0.1");
    zauth_configure_curve (auth, "*", ".curve");

I try to figure out how I would the call to zauth_configure_curve with this go package.
I found the certstore strcut which would be part of this, but it's not used anywhere else in the code.

Am I missing something or is this feature not (yet) implemented?

@erkki
Copy link
Contributor

erkki commented Jan 15, 2020

@soupdiver is this still relevant?

@soupdiver
Copy link
Author

@soupdiver is this still relevant?

I don't know... I guess my question still stands but I'm not working on this anymore 😅

@izzymg
Copy link

izzymg commented Feb 14, 2020

Also wondering about this, if a server needs to authenticate allowed client public keys, is there any way to do this using these bindings? From docs:

This gives us three possible security models
...

  • Where all clients share the same public key, that the server checks. In this case access to the server will be restricted to authorized clients. This fits the model of a private network over public infrastructure. Note that the client public key can be stolen, but cannot be used unless an attacker also steals the client secret key.
  • Where each client has its own key, that the server checks. In this case the server can grant access to clients according to their authenticated identity. Again, an attacker may steal the client public key but cannot do anything with this unless it can also steal the client's secret key.

@izzymg
Copy link

izzymg commented Feb 14, 2020

To answer my own question: auth.Curve("dir/with/allowed_certs") seems to do the trick - if you want to allow any clients, replace with "*". Otherwise any public certificates will be read from that directory on an incoming request in order to verify.

@erkki
Copy link
Contributor

erkki commented Feb 15, 2020

@izzymg to have custom logic for this, you would need to allocate a rep socket to "inproc://zeromq.zap.01”, as per https://rfc.zeromq.org/spec/27/ . Then you can use custom logic to answer the ZAP query (authenticate against a db, etc)

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

No branches or pull requests

3 participants