Client-side CSR autogeneration (take 2)

[LiptonB]

Clone of PR #10 to see if CI picks up the right commits this time

[martbab]

From Travis CI logs it looks like a correct branch was fetched this time.

[HonzaCholasta]

I guess you should also add python3-jinja2 build dependency below.

[LiptonB]

Good point. I also realized that I had the jinja2 dependency on the ipalib package, but it's actually the ipaclient package that needs it now. So I added it to both the python2 and python3 ipaclient packages.

[tiran]

@LiptonB thanks a lot for resuming your work!

Please add jinja2 to ipaclient/setup.py, too.

[LiptonB]

@tiran Thanks to the team for resuming the review, too! Added the dependency, does that look right?

[tiran]

@LiptonB yes, it's correct.

[HonzaCholasta]

@LiptonB, there's still one issue which I'd like to be resolved in this PR, and that's that currently CSR templates are tied to certificate profiles. IMO this needs to be changed, as certificate profiles in IPA are Dogtag-specific, but Dogtag is not required to generate CSRs with this feature, and it should be possible to use this feature even in CA-less mode when Dogtag is not installed and certificate profiles are not available. Luckily this PR has no hard dependency on certificate profiles, with the exception of the validate_profile_id() call and the inclusion of the userCert profile, both of which I would like to be removed before the PR is merged.

[LiptonB]

@HonzaCholasta, I think I see what you mean about these templates not being dependent on dogtag, and I'm fine with removing the userCert dogtag profile from this PR if you don't think it's relevant. Is it ok to leave the userCert CSR generation profile, as an example of what the tool can do?

So, do you mean we should no longer consider CSR generation profiles to be associated with IPA profiles? In https://github.com/LiptonB/freeipa/tree/local-cert-build I have code that allows you to run ipa cert-request --autogenerate --principal someserver --profile-id caIPAserviceCert and get a cert for the server back in one step. It uses the caIPAserviceCert CSR profile to make a CSR that works with the caIPAserviceCert IPA profile. So it seems to me that having the profiles linked makes the cert generation experience simpler, and that was the original way this feature was proposed to me. But, if you'd rather have them not be linked, should I modify this command so the CSR profile is specified with a separate flag from the IPA one?

[HonzaCholasta]

@LiptonB, I think certificate profiles and CSR generation profiles / templates should be associated, but not by sharing the same logical certprofile object, as it creates an unwarranted dependency on Dogtag. Instead CSR templates should be represented by their own dedicated objects separate from certprofile objects, which can contain a reference to the default CSR template object. This way it will be possible to extend cert-request as you described, but it will also be possible to generate a CSR and submit it to an external CA, even in CA-less IPA deployment.

As for userCert, removing just the dogtag profile but keeping the CSR template is exactly what I meant.

[LiptonB]

@HonzaCholasta, I think we're on the same page, then. I removed the dogtag profile and the validation from the profile_id parameter, and rebased the PR against master.

For the cert-request --autogenerate functionality, I will think about where in the CSR profile to store a link to the IPA profile to use.

[HonzaCholasta]

@LiptonB, I meant it the other way around - certprofile should have an (optional) attribute which points to the associated CSR template.

[HonzaCholasta]

Before I push this, could you please:

• squash "Fix broken tests in CSR autogeneration" into "Add tests for CSR autogeneration",
• add module prefix to commit subjects ("csrgen:", "tests:", etc.),
• make the terminology used in commit messages consistent ("CSR generation" vs. "CSR autogeneration", "certificate mapping" vs. "cert profile" vs. "CSR generation profile" vs. "CSR template" vs. ... - FTR my favorites are "CSR generation" and "CSR template")

?

[LiptonB]

@HonzaCholasta, updated, please take a look. I standardized on "CSR generation profile" because the names of the objects in the code and the directory that stores them are already "profiles," and because "template" is what the code calls the Jinja2 syntax that's built from the profile and the rules. But if you strongly prefer "template" to mean the collection of rules to use for generation I'm ok with changing it, I'd just want to change the code and filenames to be consistent as well.

Thanks for clarifying about the reference from certprofile to the CSR profile rather than the other way around. That seems fine to me too, especially if it's considered a default CSR profile rather than the only allowable one. Should I add that field to certprofile when I make the PR that adds cert-request --autogenerate?

[HonzaCholasta]

@LiptonB, "CSR generation profile" works for me. Once the new design is implemented though, "CSR template" will be more fitting IMO.

I would not add the certprofile field before CSR generation is moved to server. For now it should be sufficient to assume that associated certificate profile and CSR generation profile have the same name (i.e. what this PR does).

[HonzaCholasta]

Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/10ef5947860f5098182b1f95c08c1158e2da15f9
https://fedorahosted.org/freeipa/changeset/fc58eff6a3d7fe805e612b8b002304d8b9cd4ba9
https://fedorahosted.org/freeipa/changeset/f1a1c6eca1b294f24174d7b0e1f78de46d9d5b05
https://fedorahosted.org/freeipa/changeset/afd7c05d11432304bfdf183832a21d419f363689
https://fedorahosted.org/freeipa/changeset/a26cf0d7910dd4c0a4da08682b4be8d3d94ba520