Implementing Single Sigon for ASP.NET and Classic ASP websites

https://stackoverflow.com/questions/8479639

14-03-2021
|

Question

We have two old websites in Classic ASP and few websites in ASP.NET 2.0. Our new development is in ASP.NET as well and gradually we might be moving our Classic ASP sites to .NET as well. All these websites use same back-end database.

For now we are planning to move our user authentication to a single server and start using Single-Sign-On(SSO). I am not able to decide what would be the best or right way. Our asp.net websites uses FormsAutentication with CustomMembership and RolesProvider i.e. we use our custom tables instead of default aspnet_membership tables.

Ways I can think:

1: Use Webservice: I can move the authentication code to a webservice and all of our sites can use it. But I am not sure how the Single-Sign-on fits in when we have ClassicASP sites involved.

2: I heard of DotNetOpenAuth: Our external users are created by our internal staff. They can only login using the username/password we provide. So they cannot login using Google,Yahoo or any other username/passwords. So I am not sure if DotNetOpenAuth fits in our case. I saw SSO sample in DotNetOpenAuth download but have no clue how to begin.

If anyone can point me in right direction please. I have gone through various articles and docs but not getting a clue where to begin.

La solution

Checkout this guide on "Claims-based Identity and Access Control". The chapter 3 especially: "Claims-based Single Sign-on for the Web and Windows Azure" (Azure is not a requirement).

It well explains the modern Microsoft's way of implementing a single sign-on strategy.

Plus, this TechNet article helped us a lot to get started with WIF and ADFS 2.0.

Autres conseils

Well, it could be that one of passive single sign-on protocols could be your choice. You can choose between the WS-Federation, SAML protocol or Shibboleth but the first one, WS-Federation is easily supported on .NET with the Windows Indentity Foundation subsystem.

The way WS-Federation works is that it you externalize the authentication/authorization to a separate web application (so called Security Token Service). Each of federated client applications (so called Relying Parties) rely on the information provided by the service.

The basic control flows is like this:

the client points his/her browser to a RP application
the browser redirects (302) to the STS
if STS was visited and the user is already logged into the STS go to 5.
STS shows the login page and validates the user
STS returns to the browser a page containing a signed XML token with all the auth information as well as a tiny javascript to redirect to the RP application
the RP application picks up the token and creates its own authentication based on the provided information

WIF gives you tools to build both STSes and RPs easily and integration of legacy application is also simple - you can either make an effort to handle the protocol at the legacy application level or provide a "brige", a .NET application using WIF which relies on STS and passes the auth information to the legacy application.

What is also great is that with WIF you still stick with old, good notions like Forms Authentication and Membership Providers - it could be a preferred choice of STS implementation.

The WS-Federation protocol itself not only provides the single sign-on but also lets you easily handle single sign off (which is not supported by some other protocols like openid).