lerenn / asyncapi-codegen

An AsyncAPI Golang Code generator that generates all Go code from the broker to the application/user. Just plug your application to your favorite message broker!
Apache License 2.0
78 stars 21 forks source link

Support configuration of broker authentication and TLS #169

Closed magraef closed 2 months ago

magraef commented 3 months ago

In real-world scenarios, utilizing authentication and TLS encryption is mostly necessary for connecting to brokers. The various broker implementations should allow the user to configure credentials, auth mechanism and TLS.

lerenn commented 3 months ago

That would be a great addition ! And we don't have the necessity to implement it for every broker (yet). Do you a particular broker in mind ?

I would see it as a WithAuth and WithEncryption for each broker, but if you have a better idea, feel free to propose :)

Also, I am working currently on this bug and, as we discussed on another issue, I plan on doing a contributors documentation. So I won't have the time to do it right now, but feel free to do it for the broker that you use if you want to. I would be glad to see another PR ! Otherwise, no worries, I'll do it when I'll have the time :)

magraef commented 3 months ago

Yes, I'll have a look at it in the next few days. I mainly work with Kafka and would start with that. I had similar thoughts as you with the configoptions in mind, but I'm not yet sure how we can map the different auth constellations in an comprehensible way and without duplicating to mutch stuff from the client libs. I will have a look and make a suggestion.

magraef commented 3 months ago

After checking out different clients for brokers, it seems like making one solution that fits all brokers won't be easy. Each client works quite differently.

To make sure we're staying true to how each client works, it's best to closely follow their setups. Given that I assume most users of this project already have experience implementing broker connections, I believe such users will navigate more quickly if they're already familiar with the corresponding go client. Especially with NATS, there's a neat way to set up connections using functional options.

So, here's what I suggest:

  1. For Kafka, we could create two ControllerOptions.
func WithTLS(tls *tls.Config) ControllerOption {
    return func(controller *Controller) {
    }
}

func WithSasl(sasl sasl.Mechanism) ControllerOption {
    return func(controller *Controller) {
    }
}
  1. For NATS, we'll stick with how things are already set up and let users configure connections using a ControllerOption. The user would also benefit from this, because he can make further configurations to the connection if needed without further adjustments or adding bunches of different controller options:
func WithConnectionOptions(opts ...nats.Option) ControllerOption {
    return func(controller *Controller) {
    }
}

We can then pass the opts on creation of the connection down to the nats connection:

nc, err := nats.Connect(url, c.natsOpts...)
if err != nil {
       return nil, fmt.Errorf("could not connect to nats: %w", err)
}

What do you think?

lerenn commented 3 months ago

It seems good to me !

For the per-broker solution, I think that's the best and easiest solution as this is not dependent on the code, but on the broker directly and their implementation. So please, do not hesitate to implement them !

Thanks for the proposition ! 😃