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

Reply via email to