Lately I’ve been fielding a lot of questions on single sign-on (SSO) and high availability. This post provides basic advice and considerations for using these two strategies together.
Most businesses today understand the value of high availability (HA). Many have purchased sophisticated (and often expensive) third-party software packages to help them implement their HA strategy. The goal is to ensure that if something bad happens to their production system, they can easily and quickly switch to a backup system that is fully configured with all of their software and production data fully up to date.
Why is this so important? Because downtime for the production system translates to huge losses for most organizations.
It turns out that HA is just as important for single sign-on (SSO) as it is for production data! After all, what good is having an exact mirror image of your production system on your backup system if none of your users can access that data?
It’s not clear, however, that organizations who have implemented SSO have given much thought to what needs to be done to ensure that SSO continues to work after a failover to the HA system.
So what is involved in providing HA for SSO? To be certain, the approach you take to implement SSO impacts how much additional effort, if any, you’ll need to expend on HA for that approach.
Password Synchronization and Third-Party Solutions
For example, an SSO strategy based solely on password synchronization will only require ensuring that the synchronization server is available on the backup system and that all workstations are configured to use the HA system after failover. But if you employ a solution that stores your userIDs and passwords for various systems, applications, and websites, you’ll need to make sure that the server and the userID/password cache are covered in your HA strategy. Third-party SSO software packages should include support for HA.
The Kerberos and EIM Approach
The Kerberos and EIM approach to SSO involves merely using the technology already available on your system, so there’s no obvious HA support or documentation. But HA capability does exist for this approach. And — no surprise here — it also involves using the technology you already have. HA for this SSO approach must cover — wait for it — Kerberos and the EIM repository.
For Kerberos, you’ll want to ensure that the Kerberos configuration and keytab files are correctly configured on your HA system. Further, if your HA strategy does not include IP address takeover, you may need to add extra entries to the keytab file on the production machine, and a user or computer account to your Active Directory configuration for the HA system’s IP address. In addition, you’ll want to make sure that an up-to-date EIM repository is available for the HA system to use.
Since the Kerberos configuration and keytab files do not change very often, some organizations choose to manually copy these items to the HA system. If you have a third-party HA package that supports stream files, however, a more foolproof mechanism would be to use that package to make sure that these files remain synchronized between the production and HA systems.
If you have multiple production systems and a single HA system, this process is more complicated. One approach is to merge the keytab files from all production systems into a single keytab file and to have a copy on the merged keytab file on each production system as well as the HA system.
In many organizations, the EIM repository changes relatively often, usually because of seasonal hiring. This makes a more formal HA implementation a requirement.
EIM Repository Replicas
Before discussing the details of HA for EIM, a few comments on the nature of EIM are appropriate. I always refer to a “copy” of the EIM repository as a replica. This is because EIM is an enterprise resource, no different from Active Directory (AD), for example. And like AD, while you have multiple copies of the information on multiple domain controllers, you manage the information only once. When you update the information in AD on one domain controller, the other copies are automatically updated. In Windows domain parlance, this process of automatically updating the other domain controllers is called “replication.” So while you could choose to manage multiple copies of an EIM domain, I would never recommend doing so. I strongly recommend using EIM repository replicas; that is, while you have multiple copies of the EIM repository, anytime you make a change to one, the others are updated automatically.
There are two main considerations for HA for EIM: 1) how many replicas you should manage; and 2) what technology to use to manage those replicas.
The correct number of replicas to use is highly dependent on the needs, requirements and overall HA strategy employed by each organization. However, there are two basic options from which to choose:
- A replica for each production, development and QA system/partition or
- A total of two EIM replicas regardless of the number of production, development, QA, HA, etc. systems/partitions.
The rest of this article will use the term “system” to mean systems and/or partitions.
The “one replica for each system” approach is fairly straightforward. Each system has its own EIM replica. This is conceptually easy to understand. No system is dependent on any other system for successful single sign-on.
However, as the number of systems grows, the complexity of managing replica relationships between all of them grows exponentially. If you have 10 systems, for example, each of them would have an EIM replica relationship with 9 others. No single system would have the same 9 relationships. More sophisticated replication strategies (e.g. a mixture of read-only and read/write replicas) would need to be implemented to make this manageable. The precise strategy would also depend on your overall HA strategy for those systems.
Another approach for EIM high availability is to have one replica of the EIM repository regardless of the number of the number of additional systems that need to use that repository. For example, if you have a production system, a development system, and an HA system, you might choose to have one EIM repository on the production system and one on the HA system. The development system would be configured to use the EIM repository on the production system. Assuming the HA system takes over the TCP/IP hostname of the former production system, then SSO to the development system would work as soon as the HA system comes on line.
Now assume you have 10 production systems and a single HA system. This same approach could be used. One of the production servers would host the production EIM repository and the HA system would host a replica of the EIM repository. The other nine production servers would be configured to use the EIM repository on the 10th production server. The HA system would be configured to use the EIM repository hosted on that system. If one of the nine production servers failed and was replaced by the HA system, no configuration changes would need to be made on any of the original production servers. Likewise, if the production server hosting the EIM repository failed and was replaced by the HA system, as long as the HA system took over the TCP/IP hostname of the failed server, no SSO configuration changes would need to be made.
The advantage of having a single EIM replica is simplicity. A single replica will cost less to implement and manage. The potential disadvantage is associated with how long it may take for the HA system to come on line. If the production server hosting the EIM repository fails and it takes a relatively long time for the HA system to come on line, users attempting to log in to the other production systems during this time will not be able to do so.
The EIM Repository Replication Process
Once we decide on the number of replicas we’re going to use, we have to figure out how to implement the replication process. We again have two choices: use the same software as we use for our general HA implementation, or use LDAP replication.
Most third-party HA products can manage replication for EIM. My experience, however, has been that most HA vendors aren’t even aware that their products can do this.
EIM is implemented on top of LDAP (IBM Tivoli LDAP Server for IBM systems and OpenLDAP for UNIX™ and Linux systems). LDAP data is stored in libraries/directories and files/stream files. As long as you include the appropriate data files and libraries/directories in your HA software’s configuration, EIM will be replicated. Of course, you have to do a bit of investigation to determine the names and locations of the data files. Plus this information can change from one release to the next, so watch out for that.
Another mechanism to use for replicating the EIM repository is the LDAP server on which EIM is implemented. Most LDAP servers include the concept of replication whereby changes made to one server are automatically made to other replica servers. Since all of the information for an EIM repository is stored in LDAP, LDAP replication can be used to replicate all of this information.
LDAP replication provides a bit more flexibility because you can choose between peer-to-peer (sometimes referred to as multi-master) and master/replica (sometimes referred to as master-slave.) When using peer-to-peer replication you can update any replica and those changes will be automatically reflected in the other replica(s). In master/replica replication only the master can be updated. The replica is read only. Master/replica replication can be useful when a larger number of systems are involved. The advantage of using LDAP replication is that your SSO HA strategy is not dependent on the underlying LDAP implementation.
Like most things in the IT world, there are many ways to “skin the HA for SSO cat.” This is good from the aspect of being able to support just about any scenario imaginable; it’s bad because it requires a fair amount of knowledge just to know what the options are, not to mention how to implement the chosen option.
Since most system administrators already have too much on their plate, consider engaging an SSO expert (like yours truly) to get the job done quickly and correctly. As part of our SSO stat! service, Botz & Associates offers an HA for SSO “expansion pack” that includes design, implementation, and on-going service for your HA for SSO requirements.
Let me know if you would like to talk about your HA for SSO situation. I’d be happy to help!
