Proposal: Splitting Out Authenticators

[jonahx]

Proposal: Splitting Out Authenticators

Background

The Conjur core team and the 3 IL teams share the Conjur code base, but work in different parts. Currently, the teams sometimes block each other's work. Sometimes this is because one team is waiting for a review or feedback from another team, or sometimes one team makes a change that breaks the CI pipeline for another team, or otherwise impacts them.

Idea

We would like to break up the Conjur code base along team lines, so the teams can work more independetly, without worrying about affecting other teams.

Gemify Ruby Authenticators

Since the IL teams work primarily on authenticators, we want to start there.

The basic idea will be to move the authenticators -- and all authenticator tests -- into their own repository. Each authenticator will be a separate gem. However, we won't need separate repositories for each authenticator, but can use a single repository for all of them. Within that repository, each authenticator will live in its own local gem folder.

CI Benefits

The tests for the authenticators would move into the CI for the authenticators repository.

This would automatically speed up the Conjur CI, and remove most of the flaky tests there. The teams owning the authenticators could then improve those tests, or turn them off, as they saw fit, on their own timelines.

Scope / Technical Details

We would need to update the interface required for ruby authenticators, and then updated the individual authenticators to conform to that new interface. While this wouldn't be trivial, I don't think it would be that difficult either, beause the changes should only affect the border code of each authenticator.

The basic idea would be something like this:

1. Each authenticator would be provided an object like CreateToken that would allow it to mint new Conjur tokens and give those tokens to its authenticated users.
2. This object is passed to the authenticator by Conjur when the authenticator is constructed. Which authenticators are constructed is determined by the configuration of the specific Conjur instance.
3. All other communication between Conjur and the authenticator is via the Conjur API.

[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.