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

Third Party Site

The application ThirdPartySite simulates a remote third party site as the target site that a user is redirected to upon a successful authentication. As mentioned before, a landing page at the ThirdPartySite receives an EncryptedData string from Url and then consumes the authentication web service which decrypts the string and returns a complete set of user data. The third party application then processes the data returned and updates its database, and then programmatically logs the user into its site. If the decryption fails because of either the EncryptedData being expired or tampered with, an error message is returned to the third party application. As a demo, the user data returned to the third party is not saved into a database but displayed in a GridView.

A web reference pointing to CrossSiteAuthentication/AuthenticationService.asmx in the same solution is added to the site and named as AuthenticationService. There are two landing pages in the application simulating two different third party sites. For the demo, the code in LandingPage1.aspx and LandingPage2.aspx is exactly the same. Therefore, we only need to take a look at LandingPage1.aspx. Looking at the code in Listing 7, the page gets the EncryptedData from QueryString and requests for Parameter1 and Parameter2 which are used by the third party for its own purpose. For the demo, any code involving Parameter1 and Parameter2 are omitted. The page then declares an instance of the AuthenticationService and calls the RetrieveUserDataSet web method. If a DataSet is returned, signifying the success of the cross site authentication, this page performs necessary actions to handle the user data, and then logs the user in programmatically. Otherwise, authentication fails and an error message is displayed.

Listing 7

//request for the EncryptedData
string EncryptedData = Request.QueryString["EncryptedData"];
if (EncryptedData == null)
{
  lblError.Text = "A required parameter is missing from url. ";
  return ;
}
//Request p1 and p2 from Url. p1 and p2 are the parameters that 
//the third party app needs
string p1 = Request.QueryString["Parameter1"].ToString();
string p2 = Request.QueryString["Parameter2"].ToString();
//additional code here to process the parameters
 
//Add a web reference to your app and name it anything you like. Here it is 
//named as AuthenticationService.
//declare web service and a reference variable - ReturnMessage
AuthenticationService.AuthenticationService AuthService = new
  AuthenticationService.AuthenticationService();
string ReturnMessage = "";
DataSet ds = null;
//Call Web Method: RetrieveUserDataSet
//success: user authenticated, get a DataSet.
//Failure: user not authenticated or Url expired. Return null and error message.
try
{
  ds = AuthService.RetrieveUserDataSet(ref ReturnMessage, EncryptedData);
}
 
catch (Exception ex)
{
  lblError.Text += ex.Message.ToString();
}
 
if (ReturnMessage != "")
{
  lblError.Text += ReturnMessage;
  return ;
}
 
if (ds != null)
{
  FormsAuthentication.SetAuthCookie("LoginUser"false);
  gvUserData.DataSource = ds.Tables[0];
  gvUserData.DataBind();
}

View Entire Article

Article Feedback

Title:  
Name:  
Url: ( Optional )
Comment:  
Please add 4 and 3 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.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


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