In the IPA and Openstack use cases, secrets are stored and retrieved much more frequently than the standard PKI use case. We need to make some enhancements to improve performance.
In particular, in the PKI use case, we store archival and retrieval secrets in LDAP, so that they can be acted on asynchronously later. Moreover, these requests may often require N agents to approve the request.
In the IPA and Barbican case, we need only one agent for approvals, so the process can be simplified. In particular, we want to create express archivals and retrievals which do not have requests that are persisted to LDAP. This prevents a possible LDAP replication storm each time a secret is retrieved/archived.
Instead, the only LDAP write will be to the keyRecord during archival.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1392068
Initial commits
Counting objects: 127, done. Delta compression using up to 8 threads. Compressing objects: 100% (93/93), done. Writing objects: 100% (127/127), 44.35 KiB | 0 bytes/s, done. Total 127 (delta 72), reused 0 (delta 0) To ssh://vakwetu@git.fedorahosted.org/git/pki.git 732779d..308eb25 master -> master
Review message with testing instructions:
Based on feedback by Endi, I have reworked the patches. As Endi pointed out, it makes little sense for the client to determine whether or not a request is stored to ldap or not. This should be a server side decision.
Accordingly, I have modified retrieveKey() as follows:
When clients call retrieveKey(), three possible alternatives now obtain:
Depending on server configuration, the requests in case (2a) will be stored in ldap or will be ephemeral (in memory only).
More complicated realm based logic to determine if requests can be processed synchronously (and possibly ephemerally) will be added in a later patch.
Python client patches coming soon as well.
You can test the patches as follows:
(archive and retrieve a passphrase) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-archive --passphrase "foobar" --clientKeyID "test_1" pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-retrieve --keyID 0xc
hostname
(retrieve the passphrase using an approved recovery request) pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-retrieve --keyID 0xc pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-request-review --action approve 0x36 pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-retrieve --requestID 0x36
The above should create requests (archival and recovery) in LDAP. Add the following to CS.cfg (and restart the KRA):
kra.ephemeralRequests=true
Redo the above tests, and no requests should be written to LDAP.
Finally, test a case where more than one approval is needed. Add the following to CS.cfg and restart the KRA.
kra.noOfRequiredSecurityDataRecoveryAgents=2
pki -d . -n "PKI Administrator for laptop" -P https -c redhat123 -h hostname -p 8443 key-retrieve --keyID 0xc
This should return a recovery request ID (which will be written to LDAP). You will need another agent to approve this request before it can be used to retrieve the key.
Per PKI Bug Council of 11/10/2016: 10.4 - critical
More commits:
commit 0a6289f5d94ec238e66d05782b9fdd2207ac7e9a
Metadata Update from @vakwetu: - Issue set to the milestone: 10.4.0
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2652
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.