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

[Alexander Bokovoy]

On Mon, 25 Jul 2016, Simo Sorce wrote:
>On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote:
>> 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.
>
>Note, that the same tool *could* be used server side in the UI, should
>it be desirable.
That was what I commented on -- IPA server is IPA client too, so it can
make all the work locally and provide resulted bundle to download.

-- 
/ Alexander Bokovoy