Implementing SSO in a .NET Web Farm for several e-commerce websites with WIF?

Question

I have what I think is a fairly complicated question so I will do my best to articulate it here.

I am looking for a single sign on (SSO) solution. I am aware of many of the options out there but have ruled most of them out as I add criteria that they need to meet. Here are the criteria:

1.) The SSO must be added to an existing "system".
2.) The existing "system" consists of "X" number of websites.
3.) All of the "x" websites are e-commerce.
4.) The websites are all owned by company Y, for whom 95% of the system was built in-house.
5.) Each of the "X" number of websites is in the same Web Farm.
6.) All of the websites share the following components:

• DAL (Data Access Layer)
• Database (Carts, Orders, Users, Inventory, etc...)
• Authentication (Forms Auth in both WebForms and MVC).

7.) In order for the current environment to work, Machine Key's have already been synchronized among the load balanced servers (and have been for some time).
8.) High availability and stability is required due to a very large volume of traffic.

All of these criteria have led me down the path of WIF and a custom STS to use with our existing membership authentication services. Things like OpenID and other open source solutions all seem to lean towards cross company interoperability; Which is not needed or wanted. The ideal solution will be 100% internal and allow a user to log in on website "1", do whatever it is they want to do and then go to website "2" (also hosted behind the load balancer and potentially even on the same web server as the user was for website "1") and be logged in already.

Here is a list of alternative methods I have looked at and the corresponding reason for ruling them out (or should I re-consider some of these alternatives?).

• OpenID: This was ruled out for several reasons, mainly because my organization is looking for "in-house" SSO and integration with external websites or an ID system used with external websites is not desired.
• CAS: For the most part, this also seems like a decent alternative. Ultimately it was ruled out because the technologies it uses (Java, Apache, Maven, etc...) will require additional effort and money to understand, implement, support, and extend (Primarily a .NET Shop).
• OAuth: Seems like it is geared more towards exposing protected data via web services. Totally Custom (http://www.codeproject.com/KB/aspnet/CrossDomainSSOModel.aspx): A totally custom approach may have too high of an implementation time and security is more of a concern with this method.
• DotNetOpenAuth: Dependant / based upon OpenID.

So the question is: will WIF work in our existing environment given the load balancer and the already shared user account data accross websites or is there a better approach?

Please let me know if you need any clarification.

EDIT:

Just to clarify what I am looking to achieve (or think I am trying to achieve given the research I've done) is:

Current Setup (JPEG hosted on dropbox)
Desired Setup (JPEG hosted on dropbox)

Answer 1

ADFS v2.0 only authenticates against AD. If your current authentication method is something else (e.g. SQL Server) then you need a custom STS.

Are these applications all ASP.NET?

If so, they all need to be claims enabled using WIF.

If not, if e.g. Java you'll have to protect them with another solution e.g. OpenSSO / Ping Federate and federate this product with ADFS.

If Classic ASP, there are ways to allow ADFS to handle the authentication but authorisation is a problem. The roles will be inside a claims object which Classic ASP has no way of accessing. You could also use C2WTS for this.

Are you looking at authentication or authorisation or both? ADFS supplies the roles inside a claims object so the existing authorisation mechanism in your programs may have to change.

You can load balance ADFS sites.

ADFS can certainly enable SSO across all your sites. It also potentially allows you to federate with other sites / organisations and use external credentials (e.g. Facebook) via Azure ACS if that's something you need to consider in the future.

It also allows you to integrate with SharePoint 2010, CRM Dynamics 2010 and Office 365 all of which are claims enabled.