...
There are 3 sets of exchange certificate configurations in CONNECT, two for transport level security, and one for message level security. Each of these three configurations control different aspects of security with in within the CONNECT gateway.
Transport Level Security
...
These properties are used by the CXF web services stack for initiating an SSL connection. CONNECT currently uses certificates for three purposes, SSL, SAML Assertion signatures, and EndorsingSupportingToken Signatures (timestamp signature). The use of java system variables for certificate configuration affects both the outbound SSL, and the SAML Assertion signature. There are multiple ways of configuring outbound SSL certificates in CONNECT, the current method is to create a set of TLSParameters from scratch passing in keystores and truststores. However the CONNECT team has an open issue to investigate using the application server configuration to both cut down on configuration required as well as support network deployments where file references to the key and trust stores aren't available. Please see additional information here.proved that another method involving retrieving an SSLSocketFactory from the container's SSLContext is not only viable but works on all supported application servers.
Message Level Security
With the introduction of CXF in CONNECT 4.0, the CONNECT gateway instantly supported using separate certificates for SSL and Message level security, through CXF's inherent configuration. There are a set of properties files the CONNECT properties directory which allow adopters to configure message level security:
...
The truststore.properties file contains locations for the key store used for XML Digital Signatures. The .file entry will look on the classpath for a file name but will also accept a fully qualified path. CXF uses this trust store to determine if a particular key used to sign an incoming message is trusted. Failing this check does not mean the message is not trusted because there is not enough information in a public key to determine if the certificate which the public key belongs to has been signed by a certificate which does exist in the trust store. Failing this check would, result in requiring every exchange participants certificate as opposed to the chain of trust model. Please see GATEWAY-3146 for more details.
| Code Block |
|---|
org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=changeit org.apache.ws.security.crypto.merlin.file=cacerts.jks |
...