Back to bug 1392068

Who When What Removed Added
RHEL Program Management 2016-11-04 17:50:18 UTC Keywords FutureFeature
Matthew Harmsen 2016-11-10 23:59:16 UTC Version 7.3 7.4
Matthew Harmsen 2017-03-03 19:25:07 UTC Status NEW POST
Ann Marie Rubin 2017-03-03 20:28:07 UTC CC arubin
Matthew Harmsen 2017-03-15 07:35:53 UTC Status POST MODIFIED
Fixed In Version pki-core-10.4.0-1.el7
errata-xmlrpc 2017-03-15 07:42:27 UTC Status MODIFIED ON_QA
Sumedh Sidhaye 2017-05-04 06:12:33 UTC CC alee, ssidhaye
Flags needinfo?(alee)
Sumedh Sidhaye 2017-05-04 13:28:47 UTC Flags needinfo?(alee)
Sumedh Sidhaye 2017-05-05 10:09:41 UTC Status ON_QA VERIFIED
Matthew Harmsen 2017-07-13 00:50:59 UTC Assignee rhcs-maint alee
Ade Lee 2017-07-20 04:25:57 UTC Doc Text Feature:

In some cases, storing the recovery and storage requests of secrets in LDAP is not needed. A mechanism is provided to avoid this step.

Reason:

Before this feature, whenever a secret was stored or retrieved from the KRA, key requests were stored in the LDAP database. This is a legacy of the legacy retrieval mechanisms via the web UI where manual approval by N agents was required and state needed to be saved.

In the Barbican or IPA case, though, there is no need to store these requests in LDAP as they are acted on immediately and only 1 agent is required.

Storing the requests in a high use environment may trigger a replication storm.

Result:

To avoid this, we provide ephemeral requests. In the internal KRA processing, the requests are still created and acted upon, but they are not stored in the database.

Note that storage and retrieval is still properly audited in the audit logs.

To use ephemeral requests, simply set the following parameter in CS.cfg:

kra.ephemeralRequests=true
Doc Type If docs needed, set a value Enhancement
Ann Marie Rubin 2017-07-20 12:56:54 UTC CC arubin
Marc Muehlfeld 2017-07-24 15:01:43 UTC Docs Contact mmuehlfe
Doc Text Feature:

In some cases, storing the recovery and storage requests of secrets in LDAP is not needed. A mechanism is provided to avoid this step.

Reason:

Before this feature, whenever a secret was stored or retrieved from the KRA, key requests were stored in the LDAP database. This is a legacy of the legacy retrieval mechanisms via the web UI where manual approval by N agents was required and state needed to be saved.

In the Barbican or IPA case, though, there is no need to store these requests in LDAP as they are acted on immediately and only 1 agent is required.

Storing the requests in a high use environment may trigger a replication storm.

Result:

To avoid this, we provide ephemeral requests. In the internal KRA processing, the requests are still created and acted upon, but they are not stored in the database.

Note that storage and retrieval is still properly audited in the audit logs.

To use ephemeral requests, simply set the following parameter in CS.cfg:

kra.ephemeralRequests=true
Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, you can now set "kra.ephemeralRequests=true" in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file. As a result, requests are no longer stored in the LDAP back end.
Flags needinfo?(alee)
Ade Lee 2017-07-26 16:03:48 UTC Doc Text Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, you can now set "kra.ephemeralRequests=true" in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file. As a result, requests are no longer stored in the LDAP back end.
Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing state is not required. For performance reasons, you can now set "kra.ephemeralRequests=true" in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file to no longer store requests in the LDAP back end.
Flags needinfo?(alee)
Marc Muehlfeld 2017-07-27 05:37:23 UTC Doc Text Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing state is not required. For performance reasons, you can now set "kra.ephemeralRequests=true" in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file to no longer store requests in the LDAP back end.
Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing the state is not required. To improve performance, you can now set the "kra.ephemeralRequests=true" option in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file to no longer store requests in the LDAP back end.
Marc Muehlfeld 2017-07-27 13:35:20 UTC Doc Text Certificate System now supports ephemeral requests

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing the state is not required. To improve performance, you can now set the "kra.ephemeralRequests=true" option in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file to no longer store requests in the LDAP back end.
For better performance, Certificate System now supports ephemeral

Before this update, Certificate System key recovery agent (KRA) instances always stored recovery and storage requests of secrets in the LDAP back end. This is required to store the state if multiple agents must approve the request. However, if the request is processed immediately and only one agent must approve the request, storing the state is not required. To improve performance, you can now set the "kra.ephemeralRequests=true" option in the `/var/lib/pki/<instance>/kra/conf/CS.cfg` file to no longer store requests in the LDAP back end.
errata-xmlrpc 2017-08-01 22:48:25 UTC Status VERIFIED CLOSED
Resolution --- ERRATA
Last Closed 2017-08-01 18:48:25 UTC
Dinesh Prasanth 2020-10-04 21:18:43 UTC Link ID Github dogtagpki/pki/issues/2652

Back to bug 1392068