This deployment scenario has clustered mail servers along with a cluster of Domino Server with Shindig. This is the most common production deployment. In the diagram the mail servers are shown as clustered but they do not need to be. Any number of clustered or non-clustered servers can be configured to utilize a Cluster of Domino Servers with Shindig.

Domino Mail Server Cluster

The Widget catalog will live on the cluster and use cluster replication to keep all replicas in sync. The widget catalog holds a reference to the Credential Store on the Shindig cluster, and so should not be replicated with Widget catalogs utilizing a different Credential Store instance. If not use iNotes, the Widget Catalog can be located on any Domino server to which the Notes clients have access.

See this article for setting up a cluster with Domino.

See the Cluster and Advanced Configuration section of Database Creation and Configuration for recommendations regarding the Widget catalog.

An SSL certificate needs to be installed for IBM iNotes access.

SSL certificates from the Reverse Proxy need to be installed into the Domino Mail Server cluster to ensure trust between the two when making calls to the Shindig Cluster.

Load Balancer/Reverse Proxy

A reverse proxy is recommended for production environments because IBM Domino does not support TLS for modern, secure connections over HTTPS. It also does not provide the kind of HTTP load balancing necessary for production environments.

SSL should be terminated at the reverse proxy to ensure clients can utilize a TLS connection. SSL can be used between the reverse proxy and the individual Domino with Shindig cluster members, using a private SSL certificate if required, for end to end encryption.

Two SSL certificates must be used, one for the Domino with Shindig cluster host name, and one for the locked/unlocked domain which will be a wildcard SSL certificate. The wildcard SSL certificate must match the wildcard DNS entry. See Server Centric Settings for more information on Locked Domains.

The certificates need to be installed such that the FULL certificate chain is presented. This is necessary in order to accommodate the Notes embedded browser and is accomplished by creating a client SSL profile which has the intermediate and root CA certificates. This may or may not be applicable depending on the source of the certificate, but be sure to ask the certificate provider about intermediate certificates.

Domino with Shindig Cluster

The Credential Store will live on this cluster and use cluster replication to keep all replicas in sync. Any other form of replication is NOT supported. This ensures that the correct encryption keys are used and available for access from the widget catalog.

Create the Credential Store paying special attention to the extra steps required for a Cluster in Database Creation and Configuration

When configuring the managed account, where the Domino LTPA token will be obtained from a Cluster, the Reverse Proxy hostname cannot be used. Instead one of the Domino servers in the cluster must be specified using the Notes canonical name /. See the following SPR and Technote for instructions on how to enable fail over, so if the specified Domino server goes down, another one in the cluster will provide the token.

SPR Link to fixlist.

Technote Link to support.

Considerations for SSL on a Domino (with Shindig) Server

Instructions for Setting Up SSL on a Domino Server

Using HTTPS when Rendering OpenSocial Gadgets


OpenSocial Component on Domino using TLS or SSL



IBM Notes and Domino includes root certificates for most of the common Certificate Authorities, so that SSL certificates from those authorities will be trusted. If using an SSL certificate from a self signed source, or other CA, it is necessary to push that certificate to the IBM Notes client. There is code in the OpenSocial component that will add a security exception for trusted certificates pushed this way in the embedded browser, such that gadgets rendered over SSL will render properly. The first time a gadget is rendered for the end user, they may experience a flicker as the gadget renders, fails due to the SSL ceritifcate not being trusted, creates an exception in the browser, and then re-renders correctly. This will happen only once, unless the browser cache is deleted. See Pushing Certificates to Clients Through Security Policy Settings

Putting it all together

The following illustrates the high level data flows, and where the three (or more) SSL certificates are installed by color.

The Domino Mail Server can be a single server, multiple servers which replicate with each other, or a Domino Cluster. For iNotes to render gadgets, each Domino server must have a replica of the Widget catalog. An SSL certificate is used to secure https traffic for iNotes users. Notes users access the server over NRPC, which is secured using the user's Notes ID.

SSL terminates at the Reverse Proxy, so that the clients can use TLS, the best protocol for HTTPS. The Reverse Proxy requires two SSL certificates, one for the Shindig Gadget Server, and a wildcard SSL certificate for the locked/unlocked domain.

The DNS must have a static entry for the Domino Mail Server and Shindig Gadget Server, and a wild card entry for the locked/unlocked domain. These entries must match the SSL certificates.

To support more than one Domino with Shindig server, they must be setup in a Domino Cluster. Securing the connection from the Reverse Proxy to the Shindig Cluster is optional and can be achieved using self signed or public SSL certificates, since only the Reverse Proxy needs to trust these, not the clients.

Each Domino with Shindig cluster mate contains a cluster replica of the Credential Store. The Reverse Proxy must maintain session affinity between the client and the Domino with Shindig cluster mate for the "OAuth Dance" to complete successfully. Cookie based session affinity is recommended, especially in cases where client's IP addresses may change due to switching between wireless access points.