Proposal: Splitting Out Authenticators about conjur

[ismarc]

The release, testing and promotion flow needs to be well thought through up front. We already have technical debt re: internal dependencies not being updated until the moment of release. In particular, does the authenticators depend on conjur for builds/CI, which conjur version is used, etc, and then what images/how do downstream projects that depend on conjur consume a conjur+authenticators image and where (and when) is that image created?

[orenbm]

thanks for doing this @jonahx ! As we also want to go in the direction of pluggable authenticators, which should not be fully-coupled to Ruby, we need to verify that the proposed change does not take us further away for that. It doesn't need to get us closer but at least not to make it harder for us to do it.

[orenbm]

Also - can you please elaborate in the doc how Conjur will consume the authenticators? how will it be done in each project (OSS, appliance, Conjur on RHEL, SaaS)?

[Tovli]

Thanks for raising this @jonahx
I think this proposal can greatly improve our ability to develop authenticators - we could, for example, have a "conjur skeleton" to have a fast feedback loop with authn testing.
Another positive thing is that it can help us in the direction of having pluggable authenticators.

Regarding the createToken method - our authn aren't really responsible for creating tokens. they just answer the question of is the identity is from a reliable party and if the method is allowed. the token flow is the same for all authn so it can be abstracted from them IMHO. but I do agree that we will need to have some generic contract between the host (conjur) and the gem

Would be happy to see any initial design you might have

[jonahx]

Closing this as I will be opening a new issue for discussion after some experimentation and POC work.