Q:

Can a SSO service (Custom STS, WIF) be implemented so that it is highly available (clustered or in a web farm)?

I recently asked a question here: Implementing SSO in a .NET Web Farm for several e-commerce websites with WIF?  that outlines the details behind my next question.
A brief summary of the question/solution is that a series of web sites needing a SSO solution could be implemented using WIF with a custom STS to validate users against a SQLMembershipProvider of some kind.  In developing a diagram for this system, another issue presented itself.
The purpose behind the idea of web servers in a web farm is to eliminate a single point of failure (SPOF) for the websites resulting in a more reliable delivery of service.  Similar strategies are well documented for database servers and e-mail servers.  Is it possible to implement a SSO solution without introducing a single point of failure into an existing highly available environment using a custom STS and WIF?  What additional steps / strategies would need to be implemented in order to remove this SPOF?
More or less the questions are:

Can a custom STS be placed into a load-balanced environment?
Can WIF be placed into a load-balanced environment (without using a third party implementation like Azure)?
What are the specific technological issues that would need to be addressed in order to accomplish this (or could it be done in the same way that web servers are)?
Is this AT ALL a good idea?  What are some potential issues?

I have done quite a bit of research online and am unable to find a complete answer to this question.  I am still new to claims based authentication and federated identities so forgive me if I am vague or obtuse.
Am I trying to fit a square peg in a round hole?
Please let me know if you need any clarification.

A:

•Can a custom STS be placed into a load-balanced environment?
Yes - although you may need "sticky sessions"
•Can WIF be placed into a load-balanced environment (without using a third party implementation like Azure)?
WIF is just a set of .NET classes that is added as a reference in a VS project. It enables the application to be claims-enabled. You can't deploy WIF "on its own". You deploy the claims-enabled application.
•What are the specific technological issues that would need to be addressed in order to accomplish this (or could it be done in the same way that web servers are)?
For ADFS with a server farm:
"Secondary federation servers store a copy of the AD FS configuration database from the primary federation server, but these copies are read-only. Secondary federation servers connect to and synchronize the data with the primary federation server in the farm by polling it at regular intervals to check whether data has changed. The secondary federation servers exist to provide fault tolerance for the primary federation server while acting to load-balance access requests that are made in different sites throughout your network environment."
Not sure how much of this is AFDS functionality and how much is standard SQL Server functionality? You can use SQL Server to configure two or more servers to work together as a server cluster to ensure that your custom STS is made highly available to service incoming client requests.
•Is this AT ALL a good idea? What are some potential issues?
From memory, the only issue we came across was the issue of "sticky sessions".
Also, refer ADFS 2.0 High Availability and High Resiliency Walkthrough
Update: Have a look at Programming Windows Identity Foundation. The issue is that WIF session cookies are protected by the machine key. Vittorio suggests:

Sticky sessions
Synchronise machine keys
Use the SSL certificate on each machine

There's a section in the book about developing custom STS. I recommend it.

