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

[Simo Sorce]

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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York