SecureAuth and High Availability
High Availability (HA) is a broad subject that means many things to different people. In general, systems designers usually try to provide failover capability in servers, systems, and networks requiring continuous availability with a high degree of reliability. This includes everything from basic power, cooling, and connectivity in a facility in which the service or services are hosted; all the way up the stack through the host hardware (network adapters, disk, and so on) to the application itself.
SecureAuth achieves secure authentication by pairing X509.v3 certificates with the identity of a user. The public key infrastructure (PKI) is not easy to implement and maintain; and, it is important to successfully deliver secure certificates easily and at an affordable cost. The solution is to combine an on-premises appliance backed by highly resilient and available certificate signing, SMS, and Telephony services.
At its core, combining high availability and redundancy results in resiliency, including capacity. The following information details the hosted services design by SecureAuth and guidance for implementing redundant on-premises or cloud-based SecureAuth® Identity Platform services.
SecureAuth Cloud overview
Hosted services for SecureAuth are located in two physical data centers, SecureAuth US-East and SecureAuth US-West; and are redundant at the site and service levels operating in SSAE16 Type II certified hosting facilities, providing a secure, highly available (redundant) infrastructure, which includes cooling, power, network, and internet connectivity.
Also implemented is an industry leading, cloud-based, redundant geo-location load balancing solution to ensure that the Identity Platform appliance and SecureAuth Cloud Access communications are routed to the most efficient facility and, in the event of a site level outage, all communications are seamlessly transferred to the SecureAuth hosted services backup facility.
Each SecureAuth hosted services facility includes load balanced web services hosting APIs providing SMS, TTS, Push, Push-to-Accept OTP services, Threat Intelligence Services, and X.509 certificate signing services; redundant HSM (hardware security module) protected certificate authorities; and clustered (fail-over) database services supported by redundant, back-end services (i.e. LDAP Directory, DNS, Firewall, IDS/IDP, content inspection, etc.).
On-premises SecureAuth services
When designing systems for high availability, it can include the configurations of two or more Identity Platform appliances. The appliance configurations are synchronized with a front-end load balancing solution to provide the required availability for authentication services. At minimum, the redundancy and resilience level of SecureAuth services must be equal to, or preferably greater than the levels of the overall customer environment. The main topics to consider are the appliance platform, type of web service load balancing to employ, and the peak load in terms of how many authentication events occur in a given period.
 |
Overall environment considerations
As stated before, high availability can mean many things to different people. To effectively design the appropriate SecureAuth system, the overall environment and its components must be considered. Below are some of those component topics to discuss.
Customer's expectations and definition of what is considered "highly available"
Type of post authentication events to which SecureAuth provides
For example, simple workflow like a SAML assertion vs. a multi-action workflow like OWA auth post with a client browser redirect
Costs associated with adding redundant hardware and/or infrastructure
For example, appliances, load balancers, and so on
Type and availability of existing load balancing services on site
For example, hardware/virtual load balancers vs software load balancing
Infrastructure capabilities
For example, can the customer's hosting facility support redundant power drops, NIC teaming, Microsoft NLB, round-robin DNS, and so on
Physical location of the redundant systems
For example, network topology, production vs DR site
Synchronized configurations
Failover type
For example, hot/automatic vs cold/manual
Technology expertise with advanced load balancing techniques
Appliance platform comparisons
SecureAuth offers different appliance types, including virtual, base and advanced hardware appliances. The selection of the appliance platform depends on customer needs and the environment. All platforms offer the same application functionality, but some have specific advantages or disadvantages depending upon the environment. Some of the relevant platform components are briefly described as follows.
Virtual On-premise Identity Platform appliance
Virtual appliance performance is dependent on the capabilities and reliability of the host
VMotion by VMware and similar offerings can provide host-level redundancy
Virtual snapshots allow nearly instant fail-back capabilities
Nearly anything done with hardware can be virtualized
Cloud-based or hosted appliance
Available from select SecureAuth Managed Service Partners (MSP), Amazon EC2, and Skytap
Can have many of the same strengths and weaknesses as on-premises appliances
Base on-premises hardware Identity Platform appliance
Intel quad-core processor with minimum 8GB memory
Redundant disk
Redundant fan
Redundant NIC (team capable)
Advanced on-premises hardware Identity Platform appliance
Intel quad-core processor with minimum 16GB memory
Redundant disk
Redundant fan
Redundant NIC (team capable)
Redundant power supplies
Web service load balancing options
In addition to the customer environment considerations discussed above, load balancing plays an integral part of a high availability system. Overall, there are three basic load balancing methods to consider: round-robin DNS, integrated (software) load balancing, and external (hardware) load balancing.
For most customers, load balancing is usually an external appliance. However, it can be an integrated software program listening on the port (TCP 443) where external clients connect to access authentication services. The load balancer forwards requests to one of the SecureAuth Identity Platform appliances, then replies to the load balancer, and finally replies to the original requester. Many features are available with current load balancers, and the most common options are outlined next.
- Enable session persistence
SecureAuth is a state engine, therefore session persistence must be maintained between the end user's browser session (usually based on a source IP address or HTTP cookie) and the Identity Platform appliance for the duration of the authentication process.
In most cases, the duration of an authentication session lasts 3-5 seconds. For high demand and extremely high peak user support environments, you can consider the incorporation of a session database (such as the Microsoft ASP.NET State Server Protocol); this would allow scalability of the SecureAuth solution.
- Health checks
SecureAuth recommends the load balancer have the ability to poll servers for application layer health checks and remove failed servers from the pool. The ICMP (Internet Control Message Protocol) can provide availability information, however using HTTPS is recommended as the protocol for service checks.
- SSL offload and acceleration
Depending on the workload, processing the encryption and authentication requirements of SSL requests can demand heavy resources on the CPU of the Identity Platform appliance. As the demand increases, users will experience slower response times.
To remove this demand from the Identity Platform appliance, a load balancer can be used to terminate the SSL at the load balancer. Some load balancer appliances include specialized hardware to process SSL. Software-based or integrated balancers typically do not have this functionality.
When a load balancer terminates the SSL connections, the requests are converted from HTTPS to HTTP in the load balancer before being passed to the Identity Platform. As long as the load balancer itself is not overloaded, this feature does not noticeably degrade response times perceived by end users.
- CPU monitoring
A subset of load balancers support load balancing rules based on CPU use metrics of the balanced servers. When supported, it is recommended the load balancers be configured to block or queue traffic to a given server when the CPU exceeds 85%.
Round-robin DNS
A round-robin DNS is a technique used to balance the load of server requests. A DNS server with round-robin enabled has multiple different A records, each with the same domain name but a different IP address. Each time a DNS server is queried, it sends the IP address to which it most recently responded with to the back of queue, operating on a loop.
Although easy to implement, round-robin DNS has drawbacks; it cannot be depended on for site reliability. It doesn't always provide evenly-distributed load balancing because of both DNS caching and client-side caching. Also, if one of the servers goes down, the DNS server still keeps the IP address of that server in the round-robin rotation.
- Integrated load balancing
There are many software load balancing options available. SecureAuth has tested Microsoft's network load balancing but other options are equally feasible. It is important to understand any limitations of a software-based load balancing solution, such as SSL offload, Health checking and any network or protocol dependencies related to the solution. Below is a typical diagram describing the integrated load balancing model.
- External load balancing
There are many hardware or appliance-based load balancing options available. SecureAuth has tested with F5 BIG-IP, Cisco, as well as Barracuda load balancers, but other options are equally feasible. Below is a typical diagram describing the external load balancing model.
Summary
SecureAuth is built on proven and scalable technologies which allow it to support small to very large organizations. Like every deployment, success is dependent upon understanding, planning and meeting the customer's expectations. There is nothing easy about designing a large scale, reliable, and resilient SecureAuth solution. There is no "one size fits all" solution, but one thing is certain...SecureAuth can scale to meet any need