[Freeipa-devel] [PATCH] Add DRM to IPA

[Ade Lee]

On Tue, 2014-04-08 at 09:52 -0400, Rob Crittenden wrote:
> Martin Kosek wrote:
> > On 04/07/2014 10:40 PM, Rob Crittenden wrote:
> >> Ade Lee wrote:
> >>>       This patch adds the capability of installing a Dogtag DRM
> >>>       to an IPA instance.  With this patch, when ipa-server-install
> >>>       is run, a Dogtag CA and a Dogtag DRM are created.  The DRM
> >>>       shares the same tomcat instance and DS instance as the Dogtag CA.
> >>>       Moreover, the same admin user/agent (and agent cert) can be used
> >>>       for both subsystems.  Certmonger is also confgured to monitor the
> >>>       new subsystem certificates.
> >>>
> >>>       It is also possible to clone the DRM.  When the IPA instance is
> >>>       cloned, if --enable-ca and --enable-drm are specified, the DRM
> >>>       is cloned as well.
> >>>
> >>>       Installing a DRM requires the user to have a Dogtag CA instance.
> >>>       We can look into possibly relaxing that requirement in a later patch.
> >>>
> >>>       I am still working on patches for a ipa-drm-install script, which
> >>>       would be used to add a DRM to an existing master (that includes
> >>>       a dogtag CA), or an existing clone.
> >>>
> >>>      Please review,
> >>>
> >>>      Thanks,
> >>>      Ade
> >>
> >> Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be
> >> pushed ASAP.
> >
> > Oops, looks like a change that should go to IPA 3.3.x. What is the implication?
> >

This error is unlikely to have any real effect because when connecting
to the database using client auth, we determine how to connect to the
database through the parameter that defines the certificate nickname.

So we're probably fine with just changing it in master.

> >> freeipa-spec.in needs a dependency on pki-kra.
> >
> > Let us stop here. Please see a following RFE I filed:
> > https://fedorahosted.org/freeipa/ticket/4058
> >
> > I would prefer it KRA files and specifics would be in a new subpackage like
> > freeipa-server-kra. Otherwise we will need to rework it again when we would be
> > splitting CA to freeipa-server-pki in 4.1.
> 
> Yes, that is a question I didn't ask: Is the DRM going to be configured 
> by default on all new installs?
> 

The code I wrote presupposes this - but this is something that needs to
be decided by IPA.  Now given that the DRM is going to use the same
tomcat instance and database as the CA - and given that we are probably
going to want to have a DRM when we start issuing user certs, I see no
reason not to add a DRM when we add a CA.

To miminize complexity, I would suggest that we keep the requirement
that DRM requires Dogtag CA.

> > I would prefer to start the right modularization now as I do not think that
> > every FreeIPA server needs to run CA/KRA, i.e. it  does not need to have the
> > bits installed either.
> 
> I think the decision on a separate sub-package will be dependent upon 
> whether it is default or not, otherwise we can get away with 
> freeipa-server-ca and just lump everything in there.
> 

For noted above, because we will likely want DRM for user certs, I would
suggest that DRM be installed by default when we install a Dogtag CA.

As far as package dependencies, there are in fact very few additional
dependencies for the DRM as most of the Java code is in common libraries
already required by the CA.  In fact, there is only one new package
pki-kra, which contains a few KRA specific java classes.

> > I am also quite worried about the duplication that the new drminstance.py
> > introduces. There is a lot of functions which do more or less the same thing
> > and have most of the handling code the same with only a very small and
> > predictable pki/kra change. For example __http_proxy function seems to be
> > exactly the same.
> >
> > It would be great to avoid this duplication and rather have some common ground
> > utilized by both PKI and KRA. Otherwise it will be very difficult to maintain
> > the new code.
> 
> I touched on some of that too, but some of this is just inevitable I 
> think which is why I didn't pound on it too hard. An abstraction would 
> be nice, but I'm not sure abstracting for two things, and only in the 
> installer, is worth the effort. I could be wrong.
> 
This initial patch was to get things working and start some of these
discussions.  As we consider adding additional subsystems like the TKS
and TPS, having some common ground will make things simpler to maintain.

I will look into abstracting to reduce code duplication.

> rob
>