The following example shows a basic configuration for the Container file.

Artifacts are files containing resources which extend the functionality of Repose. Technically, Repose artifacts are Enterprise Application Archives (EARs).

For example, as part of the package installation of Repose (either using a DEB or RPM package), a filter-bundle-x.x.x.x.ear artifact is placed in the default artifact directory. The filter bundle artifact provides a number of filters that can be used in the filter chain, as well as descriptors of those filters. Without this artifact, Repose would not know about the filters contained within, and therefore, would be not able to use those filters in the filter chain.

The deployment process is the process by which Repose organizes the content of Artifacts in preparation for utilization.

To be more specific, the deployment process is comprised of the following steps:

Since each artifact is extracted to a directory named the hash of said artifact, deployment directory names are consistent and predictable. As a result, there will be only one copy of the extracted contents of each artifact, and therefore, disk space usage should also be predictable.

If an artifact file exists on disk prior to the deployment process, the checksum of the artifact file will be compared to the checksum of the artifact to be deployed. If the checksums match, deployment of the artifact in question will be skipped. If the checksums do not match, the artifact will be deployed, overwriting the existing artifact file. To prevent contention during the deployment process, a platform-dependent lock will be acquired on the artifact file. The lock should prevent other processes from accessing the artifact file while it is being processed. Ultimately, the checksum and locking strategy should ensure valid deployments while preventing unnecessary writes to disk and file contention when multiple Repose processes are running concurrently.

The auto-clean feature may be used to delete deployment directories when Repose shuts down. This feature helps manage disk space usage, and remove the contents of artifacts which are no longer in use. Only deployment directories created by the instance of Repose which is shutting down will be deleted.

The following assume:

The interaction between the deprecated via attribute and the new via-header element are as follows:

The following further assumes the deprecated via attribute is not defined and the via-header element contains:

There are two steps to supply a logging configuration for Repose:

If a user-supplied logging configuration file is not found, Repose programmatically sets default log4j properties. This default properties add a ConsoleAppender to the ROOT logger. The output will be formatted using a PatternLayout set to the pattern %d %-4r [%t] %-5p %c - %m%n. The default log level is set to DEBUG.

SSL/TLS Client Authentication is being used more and more for communications between different enclaves. This addition to the SSL/TLS handshake involves the Client presenting credentials to the Server in the same manner as the Server does to the Client. If the credentials presented by the Client are not trusted, then the Server will sever the connection just as the Client would have if the situation was reversed. Since a Client initiates contact with the Server, the Server’s credentials are simply to validate it is who the Client was trying to contact. This is accomplished through Certificate Authorities (CA) and the Trust Hierarchies built into the Public Key Infrastructure (PKI). Even though you can optionally add a particular Server’s credentials directly into a Client so that it will implicitly trust a particular Server essentially bypassing the distributed trust mechanism in favor of a more direct one, this is the only way to build a relationship for a Client to a Server.

To require SSL/TLS Client Authentication, set the need-client-auth attribute to True. With this setting enabled, only Clients that have a Public Key imported into the trust store referenced by the truststore-filename element will be allowed to connect. The truststore is a Java Keystore that can be created/updated using the command line tool named aptly enough, keytool. Below is an example of importing a Client certificate (client.crt) into a truststore (truststore.jks):

To use the truststore created/updated in the example above, the following would need to be added/updated in the container.cfg.xml file:

For more details, see:

Repose Valve is based on Jetty and uses its services for SSL/TLS termination. To enable this feature you need to:

Keystore information is located within the <ssl-configuration> element as shown in the following example.

Repose supports whitelisting and blacklisting specific protocols and ciphers by exposing portions of the Jetty configuration via the container.cfg.xml file. You can use this feature if a specific protocol or cipher has been compromised and you want to block its usage and harden your Repose instance. All of Jetty’s built-in default allowed protocols and ciphers are cleared and then the configured inclusion and exclusion lists are applied if an ssl-configuration is specified.

Protocols and ciphers are configured using the same process. We start with the list of all that are available on the host system. This list is culled to contain only those that match the included RegEx statements. Then the list is further culled to remove any that match the excluded RegEx statements.

In the following example, the container configuration includes only the recommended TLS ciphers and protocols. This in turn automatically excludes all SSL protocols and ciphers as they do not meet the inclusion criteria.

Certain attacks (such as Logjam) leverage the weakness of "small" Diffie-Hellman (DH) keys. To mitigate the risk of such attackers, users may either exclude vulnerable ciphers, or lengthen the DH keys used by Repose. Instructions for the former are above. For the latter, note the following:

In other words, the Java option -Djdk.tls.ephemeralDHKeySize=2048 can be passed when starting Repose to force the use of longer DH keys.

For more details, see Customizing DH Keys.

For more information about cipher suites and which ones to dis/allow when setting up Repose, see the following references:

The list of available ciphers and protocols varies depending on the JVM. We have added a command line option to Repose Valve to display the available and default enabled ciphers and protocols:

This will dump a list of the default enabled SSL/TLS parameters for the JVM you’re using. Additionally, it will list all available ciphers and protocols, should you wish to use one of those.

When running in insecure mode, Repose will accept all certificates from external services with which it communicates (e.g., authentication service, origin service).