[Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Ben Lipton]

On 07/20/2016 06:27 AM, Simo Sorce wrote:
> 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.
Honestly, my reasoning didn't go very far beyond that it seems to be 
widely used and is compatible with python, which is the language where 
the implementation is taking place (in the IPA RPC server). I thought 
about using the built-in python format strings or creating a simple 
domain-specific language, but the likelihood of wanting the built-in 
text processing features (join, replace, maybe even for loops) seemed 
high, and I didn't want to reimplement those features.

Will the additional package dependency be a problem?

Ben