[Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Ben Lipton]

On 07/25/2016 11:07 AM, Simo Sorce wrote:
> On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
>> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
>>> On 07/25/2016 05:07 AM, Simo Sorce wrote:
>>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
>>>>> Anyway, my main grudge is that the transformation rules shouldn't
>>>>> really
>>>>> be stored on and processed by the server. The server should know the
>>>>> *what* (mapping rules), but not the *how* (transformation rules). The
>>>>> *how* is an implementation detail and does not change in time, so
>>>>> there's no benefit in handling it on the server. It should be handled
>>>>> exclusively on the client, which I believe would also make the whole
>>>>> thing more robust (it would not be possible for a bug on the server
>>>>> to
>>>>> break all the clients).
>>>> W/o entering in specific +1 as a general comment on this.
>>>> If it can be done on the client, probably better be done there.
>>>>
>>>> Simo.
>>>>
>>> My thinking was that while the CSR generation must be done on the
>>> client, the retrieval and formatting of the data for the CSR should be
>>> done on the server, so that the functionality is available to all
>>> consumers of the API (ipa command-line, certmonger, Web UI, something
>>> else?). I imagine it would be relatively easy to move the formatting
>>> stuff into the ipa CLI, but all the other clients would then need an
>>> implementation of their own, and so we'd need to worry about
>>> interpreting the templates and generating CSRs in multiple different
>>> languages. It's true that as it stands a bug on the server could break
>>> all the clients, but on the other hand there's only one implementation
>>> to maintain, rather than a different one in each client.
>>>
>>> But maybe I'm not seeing the proper priorities here. Perhaps it's more
>>> of a problem because clients are easier to update with bugfixes than the
>>> server? Or maybe the preference for the client is for scalability
>>> reasons? Could you tell me more about why you prefer a client
>>> implementation?
>>>
>>> (And yeah, everything here carries a disclaimer of "I probably can't
>>> make any large changes in the remaining 3 weeks of my internship," but I
>>> think it's still good to know and document what the limitations of the
>>> current implementation are.)
>>>
>>> Thanks,
>>> Ben
>> You do not want to have to upgrade the server because tool foobarx
>> became suddenly the most used. Client tools may change over the time as
>> well, so if you try to generate stuff on the server you may end up
>> having to support multiple version with little way of knowing which
>> version that is.
>>
>> It is true that multiple client would have to implement "something", but
>> that something could be a python library+binary that other tools/script
>> can call or pipe through as needed.
> Note, from my pov the code should be more or less the same except it
> would run on the client rather than the server. Templates would be
> delivered via the same package that delivers the tool/module and admins
> would have the option to add more locally, though I am not against
> sharing templates via the server if we think that is a good idea in
> general (but the same issue vs tools changing and rendering templates
> broken with one or another version remain).
>
> Simo.
>
Ok, I definitely see your point here about making it easier to support 
the shifting versions of the helper utilities. Pulling the formatting 
out into a standalone binary that could be used by different clients 
seems achievable. The Web UI wouldn't be able to use it, I guess, but as 
of now there's no web UI for this feature anyway. I'll make sure this is 
at least documented as a desirable modification.