On Mon, 25 Jul 2016, 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.
For other clients we would need to worry about CSR, not generating them.
For them we *could* make use of the fact that IPA server is IPA client
as well and provide some API to create CSR based on a pre-defined
request type (e.g. don't support all CSR backends, just one, like
python-cryptography). That wouldn't be too flexible but for flexibility
we already accept CSRs generated by someone else.
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?
Making client responsible for generating the certificate signing
request serves several purposes where privacy is one of main benefits:
access to private key stays at the client side.
(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.)
Agreed.
--
/ Alexander Bokovoy
--
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
