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

[Ade Lee]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0159-Add-service-to-generate-and-retrieve-a-shared-secret.patch
Type: text/x-patch
Size: 67134 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20130926/f258a86a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pki-vakwetu-0160-Modify-TKS-self-tests-and-execution-to-use-new-share.patch
Type: text/x-patch
Size: 8706 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20130926/f258a86a/attachment-0001.bin>