allow loading of connectors from .so files

[amdonov]

Forgive me if this has come up before. I didn't see an issue for it. I thought it would be cool to allow developers to load connectors from .so files using Go's plugin features. I created a connector that enables this and a plugin that shows how it works.

You create the sample.so file with the following command.

go build -buildmode=plugin -o sample.so ./connector/sample-plugin/

Then, you can load it and configure it with the following in your configuration.

  - id: test
    name: test
    type: plugin
    config:
      plugin: sample.so
      config:
        name: sample
        options: limitless

Seemed like a pretty cool feature that would keep you from getting requests for new connectors all the time, and it doesn't change your API in any way.

I've had to fork dex, and I'd really like to avoid it. While the proposed grpc connector is a good idea, it's really nice not to run another process.

[ericchiang]

Plugin's are going to have the same pain as we update interfaces or deploy new versions of Go (https://github.com/golang/go/issues/17832). I don't get why this deployment strategy is better than forking dex.

[amdonov]

I'm of the opinion that forks lead to fragmentation that's not helpful. You can see it with the some of the forks for dex now. Someone might fork just to change a connector, but then they're free to change any and everything like dropping glide for modules, implementing UserInfo, etc. In most cases they're not contributing those changes back. Why go through the headaches of getting a merge prepared and approved? They can keep the change local and move on. If you provide key extension points, you can keep those developers engaged and contributing to your project.

[nabokihms]

Related issue https://github.com/dexidp/dex/issues/1907 Currently, we are working on a design dock to provide custom connectors.