Deployment scenarios
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
- Remedy SSO integrated with applications hosted on multiple domains
- Single sign-on experience enabled for applications not integrated with the same Remedy SSO server
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:
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
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:
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:
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.
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.