[Pki-devel] [PATCH] 159, 160 - allow for automated generation of shared secrets for TKS/TPS connectors

Patch 159: Add service to generate and retrieve a shared secret A new REST service has been added to the TKS to manage shared secrets. The shared secret is tied to the TKS-TPS connector, and is created at the end of the TPS configuration. At this point, the TPS contacts the TKS and requests that the shared secret be generated. The secret is returned to the TPS, wrapped using the subsystem certificate of the TPS. The TPS should then decrypt the shared secret and store it in its certificate database. This operations requires JSS changes, though, and so will be deferred to a later patch. For now, though, if the TPS and TKS share the same certdb, then it is sufficient to generate the shared secret. Clients and CLI are also provided. The CLI in particular is used to remove the TPSConnector entries and the shared secret when the TPS is pkidestroyed. Note: Patch 159 does have some code to remove the connector and shared secret on pkidestroy. This code works fine, but I plan to refactor it in a subsequent patch. Specifically, I plan to write an old legacy style servlet (DeregisterSystem.java) that will perform the operations needed to deregister a system. For instance, for a TPS deregistering on a TKS, the TKS needs to remove the TPS system user and remove the shared secret. For a TPS deregistering from a KRA, the system user needs to be removed. For a KRA deregistering from a CA, the system user and KRA connector needs to be removed. Why an old style legacy server? Because the new REST servlets do not as yet support token auth as an authentication mechanism, and to be able to support older legacy systems which do not have REST. Patch 160: Modify TKS self tests and execution to use new shared secret names The self tests and TokenServlet are modified to use the new shared secret names. A parameter has been added to allow legacy systems to continue running as-is. With a new system, the TKS self test will not fail on startup if no shared secret keys are configured. It will fail, however, if the keys are configured, but the ComputeSessionKey operation fails.