The connector feature added in #862 does not include configuration and auto-fill for the connector area during installation. This ticket is to provide that.
When completed, the tomcat tps should be able to start right after configuration, cli should work with the connectors, and browser rest interface should be able to configure properly (this currently is displaying raw xml due to the following: "This XML file does not appear to have any style information associated with it. The document tree is shown below."))
Be sure to look at the code in TPSConnectorService. This was initially an attempt to configure these connections to the TKS, although it was mistakenly placed in the tks instead.
I would suggest that it be moved from the TKS and revised to be used to handle all the connectors. You need a rest service to manage connectors -- this does precisely that.
I thought edewata already has the following rest code. Am I mistaken? pki/base/tps-tomcat/src/org/dogtagpki/server/tps/rest/ConnectionService.java It's just that it's now broken after I changed the parameter names in CS.cfg.
not sure if there is a better ticket for this note, but I just found out the TPS user on KRA is in the "Data Recovery Managers" group instead of the "Trusted Managers" group. In order for TPS to talk to DRM (KRA) properly via the connector, it needs to be put in the "Trusted Managers" group, like where the CA user is. Logically, it really should be this way anyway, since the "Data Recovery Managers" group is for the actual KRA agent users. This should be fixed in the TPS installation wizard.
example of my working connector params in TPS's CS.cfg:
tps.connector.ca1.enable=true tps.connector.ca1.host=vm-060.idm.lab.bos.redhat.com tps.connector.ca1.maxHttpConns=15 tps.connector.ca1.minHttpConns=1 tps.connector.ca1.nickName=subsystemCert cert-pki-tomcat TPS tps.connector.ca1.port=8443 tps.connector.ca1.timeout=30 tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke
tps.connector.kra1.enable=true tps.connector.kra1.host=vm-060.idm.lab.bos.redhat.com tps.connector.kra1.maxHttpConns=15 tps.connector.kra1.minHttpConns=1 tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat TPS tps.connector.kra1.port=8443 tps.connector.kra1.timeout=30 tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery
tps.connector.tks1.enable=true tps.connector.tks1.generateHostChallenge=true tps.connector.tks1.host=vm-060.idm.lab.bos.redhat.com tps.connector.tks1.keySet=defKeySet tps.connector.tks1.maxHttpConns=15 tps.connector.tks1.minHttpConns=1 tps.connector.tks1.nickName=subsystemCert cert-pki-tomcat TPS tps.connector.tks1.port=8443 tps.connector.tks1.serverKeygen=false tps.connector.tks1.timeout=30 tps.connector.tks1.tksSharedSymKeyName=sharedSecret tps.connector.tks1.uri.computeRandomData=/tks/agent/tks/computeRandomData tps.connector.tks1.uri.computeSessionKey=/tks/agent/tks/computeSessionKey tps.connector.tks1.uri.createKeySetData=/tks/agent/tks/createKeySetData tps.connector.tks1.uri.encryptData=/tks/agent/tks/encryptData
Per discussion with alee and cfu, the above parameters will be removed from CS.cfg and will be generated dynamically by a DAO. The same DAO will be used by the install wizard and the REST service. The inline documentation for configuring connector will be converted into manual pages (ticket #950). When creating a new connector, the CLI and UI should ask for the type of connector, then only ask for the configurable parameters (e.g. hostname, port).
also, please note that the configuration for failover (search for the word "Failover" in the CS.cfg for config tips) is slightly different. If you want, you can make the wizard (and ui) smarter in allowing people to configure that properly.
master:
The UI changes will be done in ticket #989.
Incorrect group will be fixed in ticket #990.
Warning about XML format will be addressed in ticket #991.
Metadata Update from @cfu: - Issue assigned to edewata - Issue set to the milestone: 10.2 - 04/14 (April)
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/1457
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.