High Availability

In most environments there is requirement to have web-services running in an Active-Active or Active-Standby configuration.

This is easily accomplished by load-balancing or configuring fail-over between two or more instances of the Orbital Lite STS.

 

Considerations

A working STS installation can be copied to one or more servers. This reduces the required configuration on each instance.

External load-balancing via network load-balancer or similar device is recommended.

Keep in mind that each new instance will require a new license file. You can follow this process to generate the request so that Radius Works can provide you the file.

As part of the request processing a user’s information may be temporarily cached on the server when requesting authentication or obtaining a fetch. This means that to generate a SAML token, the client browser may actually process one or more requests to the STS in order to complete the process. Hence it is important the user’s request return to the same server.

If load-balancing, ensure that the affinity (“stickiness”) is set to the client IP. Keep in mind that in some environments behind a proxy or a NAT this may cause undue load. It should be noted that Orbital STS Lite uses SessionIDs that are available in the request header and stored via client-side cookie.

 

Load-Balancing

Using load-balancing ensures that users are provided a resilient and potentially better-performing STS deployment.  For purposes of simplification, the clustering configuration will be based on server pairs; it is feasible that a cluster can have a larger set of servers.

There are two common configurations:

• Active-Passive
• Active-Active

Active-Passive

In this configuration, both servers have the same configuration and only one server processes requests at any given time.  The load-balancer will verify that the active node is available and will re-direct traffic to the passive node if a certain condition or threshold is (e.g. the web service cannot be reached, requests exceed a certain response time, etc).  

This configuration will work for all scenarios without any specific modifications.  It is possible that a user request may be lost during the transition from the active node to the passive one (or vice-versa).

Active-Active

In this configuration, both servers have the same configuration and both can process requests at any given time.  The load-balancer will distribute the traffic based on a specific parameter (e.g. number of connections, response time, etc).  

This configuration will work for all scenarios although for services that use UserContextMode 4, 5 or 6, the load-balancer must configure affinity ("stickiness") based on source IP address (or similar).  This is due to session handling as the information from the HIS will stored in memory while the user's browser is challenged for authentication.  In this case, the same server must process the same request.  

URLs and Virtual IP (VIP)

The VIP associated with the load-balanced configuration must have a corresponding DNS entry.  This DNS will be used for the URL that can be specified in the web.config so that the metadata.xml provided to Service Providers is meaningful.  The URL must be resolved by the client workstations accessing the Orbital Lite STS web service.  The VIP and DNS does not need to be routable (or resolvable) on the servers hosting the service itself.

We recommend that the URL is meaningful to the service provider (for convenience in case they need to troubleshoot access) and that there is an appropriate web certificate that matches the DNS entry.