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

1

7

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)

Novick answered 6/10, 2011 at 18:28 Comment(0)
C
2

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.

Cracksman answered 6/10, 2011 at 19:59 Comment(4)
The websites are all .NET, no classic. My understanding with ADFS is that Active Directory is the source that the STS validates the user's claim against (I may be mistaken). If that is the case, then ADFS is not a viable option since our membership data is not at all related to AD. Can WIF be utilized without AD? If it isn't ADFS, can it then not be load balanced? Also I believe we would need both authentication and authorization as certain pages behave differently when a users has been authenticated.Novick
The way it would work is that you would federate your STS (which authenticates against e.g. SQL Server) with ADFS. A custom STS can authenticate against anything you want. The attributes that you use for authorisation can be derived from any combination of AD, SQL Server or LDAP. You don't have to use WIF / ADFS for authorisation. You can use it simply for SSO (authentication) and leave your authorisation code as isCracksman
It seems as though your answer is correct, but could you please confirm this against the diagrams I added in the edit? Note the complete lack of anything related to AD in the diagrams. Thanks!Novick
OK - so you need a custom STS that authenticates against SQL Server. Look here - identityserver.codeplex.com. BTW, there is an ADFS proxy server.Cracksman

© 2022 - 2024 — McMap. All rights reserved.