Cross Site Authentication and Data Transfer
page 2 of 7
by Tom Zhang
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 7152/ 214

Basic Program Logic

The user clicks a formulated login link and he or she is sent to the authentication site. This link contains a QueryString parameter ReturnUrl that represents the landing page of a third party site to which the user will be redirected after being successfully authenticated. The login link looks like:

http://www.AuthenticationSite.com/login.aspx?SiteID=1&
ReturnUrl=http://www.ThirdPartySite.com/LandingPage.aspx?
Paramter1=xxx&Parameter2=yyy 

SiteID is a parameter that the authentication site uses to determine web page presentation style as well as data transfer logic (what stored procedure to use for delivering data to a third party site). Parameter1 and Parameter2 are a part of the ReturnUrl and are used by the third party site for its own purposes. The ReturnUrl should be UrlEncoded so that the whole string including parameters and any preserved characters like “?,” “=,” “&” is treated as one single parameter as the following:

http://www.AuthenticationSite.com/login.aspx?SiteID=1&
ReturnUrl=http%3a%2f%2fwww.Third+PartySite.com%2fLandingPage.aspx%3f
Paramter1%3dxxx%26Parameter2%3dyyy

The authentication site first obtains the SiteID and the ReturnUrl from QueryString and then presents the user, based on the SiteID, with a login page that has a graphic presentation similar to the third party site. The user enters his username and password, and clicks the login button. Upon a successful authentication, the application retrieves the user’s identity from the database and builds a securely encrypted url QueryString parameter, EncryptedData, that includes UserID, ExpirationDateTime and SiteID (more can be added as needed). It then appends it to the end of the ReturnUrl. The ReturnUrl now looks like:

http://www.ThirdPartySite.com/LandingPage.aspx?Paramter1=xxx&Parameter2=yyyy&
EncryptedData=RD69usAsVDrAwr3Sa8jyO9FNRmgcuyM9o3WamQ/eeDufMQZgooqn0pw+aEXEsOzs5K1a
Q3Y63RNAj8dWwrj4Yf+poMm94Jp8CO72YgyNXMJgBtzopeQcahNZXQAkry0iEDE7dgE+TUHmE1tDb3C32U
J3t+69A/aKj5cu7Kcg1G9csk6ZbKD/E73UZ89W/7mN

The user is then redirected to the landing page of the third party site using the above ReturnUrl. The EncryptedData should be UrlEncoded.

At the third party site, the landing page grabs the parameter EncryptedData from QueryString and calls an authentication web service with it. The web service decrypts the parameter and checks the expiration date. Successful decryption with a valid expiration date signifies that the user has been authenticated. The web service then retrieves a complete set of user data from database using a stored procedure determined by the SiteID and returns the data to the third party application. The landing page inserts/updates user data in its own database and performs necessary actions to programmatically log the user into its system.

To illustrate how the cross site authentication works, I have prepared a demo application for download. The solution contains two web sites. One is the CrossSiteAuthentication that provides a login interface to authenticate users as well as a web service for a third party to consume. The other is the ThirdPartySite that simulates a third party service provider site. Although both sites are in the same solution and run on local machine, the methodology is applicable to any third party site located at a remote location.

To run the demo, you will need Sql Server 2005 Express Edition (make sure that the service is running. It may be necessary to test its connection from Server Explorer in Visual Studio 2005) and Microsoft Enterprise Library – January, 2006. The enterprise library is used for data access and cryptography. Since the security key for cryptography is machine dependent, you will need to create a key using Enterprise Library Configuration Utility that comes with the library installation. Use the following steps to create a key.

·         Start Enterprise Library Configuration Utility (under Start – All Programs, Microsoft Patterns & Practice, Enterprise Library – January 2006).

·         Right click on Enterprise Library Configuration root item and select New Application. Right click Application Configuration (a newly created item below the root), and select New, Cryptography Application Block. Right click Symmetric Providers and select New, Symmetric Algorithm Provider. In the dialog box that comes up, select TripleDESCryptoServiceProvider (This is the one I used. Others should all be fine.). In the key wizard dialog box, select Create New Key and click Next. Enter some text and click Generate, Next. Give a name (I used tripleDES.key) and save it to the CrossSiteAuthentication application folder (can be saved anywhere). Click Next, select Machine mode and click Finish.

·         Open web.config file in CrossSiteAuthentication application and change the element protectedKeyFilename inside symmetricCryptoProviders to the path where you saved the key.

In Visual Studio 2005, open the solution. Expand the ThirdPartySite tree, right click on the LandingPage1.aspx and select View in Browser. When the page appears, click “Check Authentication Status” button. You will see that the user is not authenticated. Close the browser. This action is to make the ThirdPartySite accessible by starting its local web server since it is a file-system based application. Expand the CrossSiteAuthentication tree. Right click Default.aspx page and select View in Brower. Two links are shown on the page. Looking at the HTML code for these two links, you will see that one has a ReturnUrl that points to Third Party #1 web site and another to Third Party #2 web site. In the demo they are not really two sites, but two pages in the ThirdPartySite application, LandingPage1.aspx and LandingPage2.aspx. Please check the port number in the links and make sure it is a correct number for the ThirdPartySite application.

Click the link "Third Party #1 Web Site," the login.aspx page shows up with a header image and header text of Site1. Enter the user name: johnd and pw: password (or janed/password, there are only two users in customer table), and click the Login button. You are authenticated and are redirected to the LandingPage1.aspx in the ThirdPartySite. The landing page calls web service and pulls out John Doe’s data, and programmatically logs John into the ThirdPartySite. Click the “Check Authentication Status” button. This time you will see that user is authenticated. If you change the "EncryptedData" in the Url or leave the page open for over a minute and then refresh the page, you will see a message indicating decryption failed or url expired.

Repeat the above steps with the Third Party #2 Web Site link on the default.aspx page (you will see a different header image and header text) and then you are redirected to the LandingPage2.aspx after being authenticated.


View Entire Article

Article Feedback

Title:  
Name:  
Url: ( Optional )
Comment:  
Please add 1 and 8 and type the answer here:

User Comments

Title: Why redirecting when using a webservice?   
Name: Tom Z
Date: 2/6/2008 11:49:50 AM
Comment:
Hi Dave,
Thanks for your invaluable input on this topic.

No doubt that a third party can consume the web service to authenticate a user directly without going to a centralized authentication site as introduced in this article. The reasons that I choose not to do it that way include the following:
- Minimize the amount of work that a third party has to do for authentication and data transfer;
- Reduce the complexity related to finding an existing record and creating a new record. An existing user does not initially reside in the third party database (only in our database). It will be a complicated process (or a lengthy process) for the third party app to find a user in our database through web service calls. If the “finding” process is not implemented, all existing users in our database would become “new” users at the third party site. When creating a new record, the third party not only needs to create a record for itself but also to collect additional information for our specific needs and then exports this record into our database. For example, let’s say the main business type of a user is required in our database, the third party has to create this field in its database, even though it does not need this information at all.

Regarding the length of URL as well as redirecting user between authentication site and a third party site, you have valid points. However, this method is intended to be used among business partners with “trusted” relationship. The issues can be resolved through the partnership.

Thinking of Windows Live solution, would that be similar to this? The difference is that Windows Live only does authentication while this method does both authentication and data transfer. In addition, Windows Live may not need web service calls (I guess) during authentication since “Live” components come with the Windows installation.

Regards,
Tom
Title: Why redirecting when using a webservice?   
Name: Dave
Date: 2/1/2008 7:05:05 PM
Comment:
It might sound silly, why not letting the third party websites consuming the webservice AuthenticationService.asmx?

It also has some other benefits:
- The user won't be redirected to another website
- you can return all kind of information, not needed to encrypt it.
- The authentication srevice itself can be secured by passing a SiteID an a pre-shared key. Other method is IP-based access.
- No problems redirecting from HTTPS (I assume registration / login is done over SSL!) to http and browser security warnings. Because the login page is on the website self, it makes much more sense to purchase a SSL certificate.

Of course you need to implemented a few pages such as registration, forget/change password, logout etc. But the authentication 'website' doesn't need to implement a new masterpage for each site which wants to use the service.

Another issues which might can be a problem is the use of EncryptedData in the url. More and more webservers have limits on the values of a query-string parameter. Because the returned information set can become very large, it might cause problems. On our webservers (both IIS and Apache) the maximum limit of query string parameters is set to 128 bytes. Exceeding the limit results in a 414 Request-URI too long.

Another issue, partly raised earlier, is that your sending the visitor to an website where it doesn't want to be. These days there are a lot of phissing websites. Redirecting a visitor from www.example.org to www.loginservice.net can cause a visitor to leave your website permanently because he doesn't trust your website.

Webservices can also be consumed by other languages such as classic ASP , PHP and Java. And because each website is implementing it's own profile pages, it's also easier to implement an ajax-enabled forget password page for a specific website. Remember, ajax is not cool for WAP (mobile) sites.
Title: Well done   
Name: foton
Date: 12/20/2007 12:57:29 PM
Comment:
Clearly written and explained. Lots of players making big bucks marketing variations on this method. Your article will give us the jump-start we need to do this in-house.






Ads Powered by Lake Quincy Media
Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2008 ASPAlliance.com  |  Page Processed at 8/22/2008 12:57:18 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search