Can the security domain issue a short-lived certificate as a token? The certificate can be used to perform client authentication over SSL, and be associated with the user performing the installation (i.e. admin user), so it will reuse existing signing, authentication, and authorization mechanisms. That also means we can use existing CLI and Web UI to troubleshoot installation issues. Additional information probably can be included as a custom certificate extension.

@edewata possibly. But this would require the client subsystem to submit a CSR/Key, which raises some questions:

• should it be a new keypair?
• could it use an existing keypair e.g. the subsystem keypair
• should it use an existing subject name or a new subject name? a random subject name?

Alternatively, a signed bearer token is accomplished easily enough and retains the security
characteristics of the current implementation, while avoid the replication issues.

But we're a "Certificate System" after all so I'm not totally against the idea of eating some
dog food :)

My initial thought on this was something like the PKI or PKIZ bearer tokens issued in Openstack by the keystone process.
( http://blog.dolphm.com/the-anatomy-of-openstack-keystone-token-formats/

The key thing is that the tokens would be signed by the security domain CA signing cert - which is the same across all security domain clones. The token payload would include all kinds of pertinent information (such as the subsystem being installed and the associated user) and could be extended as needed - maybe to include information about the security domain.
This could eliminate the need for a subsequent call to the security domain to get this information.

Using a certificate as a token restricts the extendability of this mechanism.

Assuming the extra information can be encoded and inserted into the certificate as a custom extension, it should not have any restriction. As mentioned earlier, using a certificate as a token could probably simplify the implementation and would be compatible with existing tools.

The process may look like this:

When the admin runs pkispawn, the tool will initially authenticates against SD with a password (as in the current mechanism), or with admin's certificate. It will either generate a new keypair or reuse admin's existing key, then send the CSR to SD. The SD generates a short-lived certificate signed by the CA that contains installation information (e.g. subsystem being installed, associated user). We can figure out what the subject DN should look like when we're ready to implement this.

If we don't want to enable the password authentication, the certificate can also be issued via the normal process in CA with agent's approval.

After the certificate is issued, pkispawn can use it as a client certificate to authenticate against the target subsystem. Tomcat can already validate client certificates against the CA certificate without contacting the CA using the existing realm. The realm can be enhanced to extract certain attributes from the custom extension to generate a principal that represents the associated user with the proper rights. The principal can be used to invoke any existing REST service (e.g. adding connectors) that it has access to. It is not necessary to implement token authentication/authorization within the REST service itself.

Once the installation is complete, pkispawn can notify the SD to revoke the certificate, or the target subsystem can deny further access by the certificate, or just let it expire by itself. If something goes wrong and the certificate is still valid, the admin can manually use the same certificate with the CLI to test the failing REST service, or perform a workaround, which I think is a significant benefit over a regular token.

If we use a regular token as opposed to certificate, would it be safe against replay attack?

@edewata if a signed/MACed token can be used in replay attack if intercepted. So certificate authn is more secure (but also more complex).

Looking at the code, the default security domain session lifetime is 1 day. So we can make that
the default for certificates. Revocation adds more complexity and AFAICT there is no explicit
log out of security domain during clone configuration so we're not regressing in that regard
(please correct me if I'm wrong).

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/2951

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.