This documentation supports the 20.02 version of Remedy Single Sign-On.

To view an earlier version, select the version from the Product version menu.

Deployment scenarios

You can deploy the Remedy Single Sign-On server to accommodate a range of conditions and use cases described in this topic.

Remedy SSO installed in standalone mode

In a standalone mode, you deploy Remedy SSO on a single server, and then integrate Remedy SSO with the applications on which you would like to enable a single sign-on end user experience. When you deploy the Remedy SSO server to your environment, consider the following use cases:

Remedy SSO integrated with applications hosted on a single domain

The following figure shows the basic deployment use case when all components of the Remedy SSO system are hosted on the same domain:

Applications hosted in single domain

For example, you might have BMC Digital Workplace (corresponds to Application 1 in this figure) and BMC Digital Workplace Catalog (corresponds to Application 2 in this figure) integrated with Remedy Single Sign-On. 

Remedy SSO integrated with applications hosted on multiple domains

Applications hosted in different domains

If your applications are hosted on different domains, you must configure them to use the same Remedy SSO server for authentication. For information about how to do this, see Configuring Remedy SSO for applications hosted on different domains.

Single sign-on experience enabled for applications not integrated with the same Remedy SSO server

To enable single sign-on experience between applications that do not share the same Remedy SSO server and are deployed in different domains, you must have the Remedy SSO server deployed as shown in the following figure:

Cross-launched apps version 2

The originating application cross-launches the target application in an iframe without displaying the login page to end users. The target server relies on the JWT public certificate to validate the incoming cross-launch request from the originating server.

The originating application can be a part of a third-party system, but it can also be a part of another Remedy SSO as shown in the following figure:

Apps cross-launched from another server

To configure Remedy SSO to support this case, perform tasks described in Enabling cross launch for applications integrated with different Remedy SSO servers

Remedy SSO installed in high availability mode

To implement Remedy SSO as a redundant system with session failover, you can deploy the Remedy SSO in a high availability (HA) mode. In HA mode, multiple instances of the Remedy SSO server are deployed, and a load balancer is usually used as a front end of the HA mode. For external applications, the load balancer functions as a single server that distributes the requests over multiple Remedy SSO nodes.

Remedy SSO deployed in a high availability mode

In HA mode, Remedy SSO can be integrated with applications that are hosted on a single domain or on multiple domains. 

The end user requests can be handled by any instance because Remedy SSO does not require sticky sessions. If one of the HA nodes fails, the system failure is absorbed by the remaining nodes with minimal interruption. No additional configuration is required on the Remedy SSO side, as each node is unaware whether it works in HA mode or not. All HA mode configurations are done remotely by using the network infrastructure.

Remedy SSO in an HA mode functions as a single virtual server. Therefore, all configuration information, user sessions data, and user tokens are stored in a single database and shared (not replicated) between nodes. To prevent the database from becoming a single point of failure, database replication may be required. 


The configuration required for database replication depends on the specifics of the environment. The information about the database replication is out of scope of the Remedy SSO documentation.

Where to go from here

System requirements

Was this page helpful? Yes No Submitting... Thank you