On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote: > Hi, > > I have updated the design page > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generati > on/Mapping_Rules > with my plan for implementing user-configurable rules for mapping > IPA > data into certificate requests. In brief: we will use Jinja2 for > templating. Data rules (which map individual data items) and syntax > rules (which group them into certificate fields) will both be > snippets > of Jinja2 markup. The formatting process will be as follows: > 1. Syntax rules will be rendered using Jinja2. Data rules (rule > text, > not rendered) will be passed as the datarules attribute. > 2. Rendered syntax rules will be processed by the Formatter class > for > the selected CSR generation helper (e.g. openssl or certutil). The > formatter combines these partial rules into a full template for the > config. > 3. The template will be rendered using Jinja2. Relevant data from > the > IPA database will be available in the context for this rendering. > 4. The final rendered template will be returned to the caller, > labeled > with its function (e.g. a command line or a config file). > > Are there any comments or objections to this approach? Here's an > example > to show what it might look like in practice. > > Example data rules: > email={{subject.email}} > O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}} > > Example syntax rule: > subjectAltName=@{% section %}{{datarules|join('\n')}}{% endsection %} > > Example composed config template: > [ req ] > prompt = no > encrypt_key = no > > distinguished_name = {% section > %}O={{config.ipacertificatesubjectbase}} > CN={{subject.username}}{% endsection %} > > req_extensions = exts > > [ exts ] > subjectAltName=@{% section %}email={{subject.email}}{% endsection %} > > There's a lot more information about the thinking behind this at > http://blog.benjaminlipton.com/2016/07/19/csr-generation-templating.h > tml > if you're interested, as well.
Nice work Ben, it's been really nice to be able to follow your notes on the blog post, one question remains lingering in my head, why jinja2 ? I know that engine relatively well as I used it in ipsilon, so I am not questioning the choice just asking why specifically jinja2 and not something else, potentially language agnostic. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
