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

[Ade Lee]

On Wed, 2014-08-20 at 15:35 -0400, Rob Crittenden wrote:
> Ade Lee wrote:
> > On Thu, 2014-08-14 at 14:29 +0200, Petr Viktorin wrote:
> >> On 08/14/2014 10:53 AM, Martin Kosek wrote:
> >>> On 08/13/2014 09:54 PM, Ade Lee wrote:
> >>>> In Dogtag, we have decided to revert the name of the DRM to the old name KRA.
> >>>> DRM was really only used in docs/marketing, whereas KRA is all over the code.
> >>>> Soon, the code and the marketing/docs will match.
> >>>>
> >>>> The following patch changes all references to the DRM to KRA.
> >>>> so for example, you need to run ipa-kra-install etc.
> >>>>
> >>>> Please apply this on top of the previous patch.  I'll go ahead and squash them
> >>>> before commit.
> >>>>
> >>>> Thanks,
> >>>> Ade
> >>>
> >>> Ah, thanks for unifying that one. I changed DRM component in FreeIPA Trac to
> >>> KRA and assigned respective tickets to that. Let us use the KRA term for the
> >>> Vault then.
> >>>
> >>> Martin
> >>>
> >>
> >> ipa_drm_install.py: No newline at end of file
> >> ipa_drm_install.DRMInstaller.FAIL_MESSAGE: the command is 
> >> ipa-drm-install (with hyphens)
> >>
> > fixed
> >>
> >> The error I got previously was when running ipa-kra-install on a replica 
> >> that didn't have CA yet. It would be nice to provide a better message 
> >> for this case.
> >>
> > agreed.  the problem here was that the check to see whether a ca was
> > already installed locally was not working as expected.
> > 
> > I have since added a new check - which should fail if a CA is not
> > installed locally.
> > 
> >>
> >> On a replica with KRA, I get:
> >>      $ sudo ipa-kra-install --uninstall
> >>      Usage: ipa-kra-install [options] [replica_file]
> >>
> >>      ipa-kra-install: error: Cannot uninstall.  There is no KRA 
> >> installed on this system.
> >>
> > 
> > Not sure what happened there.  With the latest code, that does not
> > appear to happen for me.  Let me know if it recurs.
> > 
> >> I tested the kra plugin with this Python script:
> >>
> >>      from ipalib import api
> >>      api.bootstrap(context='server', kra_host='localhost')
> >>      api.finalize()
> >>      api.Backend.kra.store_secret('test', 'tkey')
> >>
> >> which gives me:
> >>
> >>      Traceback (most recent call last):
> >>        File "<stdin>", line 1, in <module>
> >>        File "ipaserver/plugins/dogtag.py", line 2012, in store_secret
> >>          self._setup()
> >>        File "ipaserver/plugins/dogtag.py", line 1965, in _setup
> >>          connection = PKIConnection('https', self.kra_host, 
> >> self.kra_port, 'kra')
> >>        File "/usr/lib/python2.7/site-packages/pki/client.py", line 36, 
> >> in __init__
> >>          self.hostname + ':' + self.port + '/' + \
> >>      TypeError: coercing to Unicode: need string or buffer, int found
> >>
> >>
> >> Apparently, PKIConnection requires the port to be a string, but we pass 
> >> an int. I'd consider this an issue in pki.
> >>
> > Agreed.  I will open a ticket to fix it in pki.  For now though, I have
> > cast to str().
> > 
> >>
> >> The kra_host='localhost' option to api.bootstrap is necessary because 
> >> kra_host is not added to default.conf on install. How is this planned to 
> >> work when the plugin is done?
> >>
> > I followed what was done for ca_host, but did not set the required
> > default in constants.py.  Thats fixed, so this should work now.
> > 
> > After discussion with Endi, I also removed some functions in dogtag.py
> > (the plugin) which basically just wrapped calls to the keyclient.  There
> > is no need to do this wrapping and it is much more flexible for IPA code
> > to call the keyclient directly.  Accordingly, I have added a method to
> > get the keyclient.  Your test code would look like this now:
> > 
> > 	from ipalib import api
> > 	from pki.key import KeyClient
> > 	api.bootstrap(context='server')
> > 	api.finalize()
> > 	keyclient = api.Backend.kra.get_keyclient()
> > 	keyclient.archive_key('test', KeyClient.PASS_PHRASE_TYPE,'tkey')
> > 
> > I added a couple of directives in the proxy file to allow it to progress
> > further and it now fails in trying to do the archive_key due to
> > authentication issues.
> > 
Did some more investigation on this.  It turns out that the problem is
in the PEM file that is generated (/etc/httpd/aliad/agent.pem)

There are in fact two problems.  One is that the agent.pem that is
available there is for the IPA RA agent, who is not an agent on the KRA.
Also, it appears that the PEM file itself may have some weirdness in its
format.

The PEM file is generated by the code _generate_pem_file() in dogtag.py.
That code will need to be re-examined and fixed.  I would like to leave
that task to Endi - as he needs to decide how/which agent will be used
to communicate with the KRA.

If you use a valid agent PEM, then the above test code works.

Here is what I did:
$ openssl pkcs12 -in /root/ca_agent.p12 -out /etc/httpd/alias/agent.pem -nodes

And then I ran the following without issues:

from ipalib import api
from pki.key import KeyClient
api.bootstrap(context='server')
api.finalize()
keyclient = api.Backend.kra.get_keyclient()

infos = keyclient.list_keys()
for info in infos.key_infos:
    print "{0} {1}".format(info.client_key_id, info.key_url)

keyclient.archive_key('test3', KeyClient.PASS_PHRASE_TYPE,'tkey')
print keyclient.retrieve_key(1).data

You can also use the pki cli utility (pki key ...) to confirm that the
KRA is in fact operational.

> > It was never the intention of this patch to get the plugin completely
> > working though.  That was the goal of a follow on patch being written by
> > Endi.  This patch is already pretty long and touches a lot of code.  I
> > propose we let Endi fix the above issue.
> > 
> > I have squashed the drm-> kra changes and created just a single patch,
> > which is attached.  This is the only patch needed.
> > 
> > I'm also starting a new COPR build, just to be sure we all have the most
> > up-to-date dogtag build. 
> 
> It doesn't look like the --no-host-dns option is used anywhere.
> 

removed in attached patch.

> I'm kinda with Petr, I don't know that an uninstall option is needed.

> On a single master install I successfully did a kra install, uninstall,
> re-install, so maybe the issue that Petr saw was related to cloning.

I investigated this error.  The failure to reinstall on the clone is due
to a bug in the way pkidestroy handles the kra connector configuration
that is created on the CA.  I have opened up a ticket to address this,
and will try to fix this issue within the next week or two.

Once this is fixed, installing/uninstalling on either a master or clone
should work without issues.

As a workaround till then, after uninstalling the master and clone KRAs,
check the CS.cfg of the master/clone CA and remove any entries that
start with ca.connector.KRA.*  And of course, restart the CA.

I propose leaving this in -- it basically works right now - except for
the issue above. 
> 
> There is no man page for ipa-kra-install
> 
Can I add this in a separate patch?

> Functionally the KRA itself seems to be working ok.

Attached is a patch with a few basic changes - mostly additional URLs
needed to make sure the script above runs.  Please apply on top of the
big one previously attached.  I'll squash before commit.

> rob
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Some-additional-minor-changes.patch
Type: text/x-patch
Size: 2957 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140821/0a5fbe7e/attachment.bin>