Cross Site Authentication and Data Transfer: ASP Alliance

Print Add To Favorites Email To Friend Rate This Article
Cross Site Authentication and Data Transfer

page 7 of 7

by Tom Zhang
Feedback

Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 20831/ 285

Article Contents:

Summary

I have discussed the methodology for cross site authentication and data transfer. The demo application is a greatly simplified version in order to illustrate the concept. In the real world, at least several additional parts have to be in place, such as "Remember Me," "Forgot My Password," "Create New Account," etc. In addition, the accessibility of the web service should be restricted to the third parties that you have a partnership with. Depending on the programming platform that a third party uses, more variations of a web method may be required to return data in an appropriate format (for example, a string array or a special character like "|" separated string, etc.) that the third party can process.

This methodology is not necessarily a good solution, rather a topic for discussion. Your comments are appreciated.

« (Page 6)

View Entire Article

Article Feedback

Comment:
Title:
Name:
Url:	( Optional )

Please add 6 and 4 and type the answer here:

User Comments

Title: Re : Can we use this to connect to a SAP IView
Name: Kalpesh
Date: 11/11/2009 12:50:26 AM
Comment:
Hi Tom,

Thank you very much for your kind reply.

I looked in .Net connector in past, but my approach is quite different. Basically, I just want to show the IView which is already there in SAP, for that I just need to authenticate myself. But any way I will look in to both your suggestions.

Thanks again.

Title: Connect to a SAP IView
Name: Tom
Date: 11/10/2009 8:46:21 AM
Comment:
Hi Kalpesh,

With this method, basically, you need to code a landing page in your target application. If you can't do it in SAP, this will not be suitable. I have not used SAP. By reviewing some documentation, it seems that SAP has a .NET connector which you may look into it. Here is an article: http://help.sap.com/saphelp_nw04/helpdata/EN/51/d5470940fd564b888f4beb9523fa6c/content.htm. If you are able to do custom coding in SAP, I have newer version: http://www.codeproject.com/KB/web-security/CrossDomainAuthentication.aspx in which encryption is replaced by a database table. See which method is a better fit.

Title: Can we use this to connect to a SAP IView
Name: Kalpesh
Date: 11/10/2009 1:55:52 AM
Comment:
Hi tom,
First of all..nice article.

I have one question regarding my requirement. I have one URL which points to the SAP IView. I also have the credentials to access this SAP site.

I have accessed/displayed that SAP IView in sharepoint using it's SSO service. Now I want to show the same thing in ASP.NET application. So can I implement the SSO(which you have given)in my asp.net application to view SAP IView.

Title: das
Name: satya
Date: 8/10/2009 5:46:34 AM
Comment:
hi i want to download this

Title: Reply: SSO from two server?
Name: Tomz
Date: 4/16/2009 9:55:39 AM
Comment:
If your two applications are running on the same second level domain, for example mysite.com (public.mysite.com, private.mysite.com are both third level domains that belong to the same second level domain mysite.com), you can write a cookie with the domain attribute of mysite.com. Both applications will be able to read the cookie. see this article: http://www.codeproject.com/KB/aspnet/SingleSignon.aspx.

If they are not on the same second level domain, you may try the methodology indicated in this article or the revised version at: http://www.codeproject.com/KB/web-security/CrossDomainAuthentication.aspx. The revised makes the implementation easier by removing encryptography.

Thanks

Title: SSO from two server?
Name: mrnothing
Date: 4/16/2009 4:26:01 AM
Comment:
I have two application on two server
I can't get session, cokie, ..etc. when user login from one application and don't login again from another. Please help me!

Title: RE: how two asp.net webservices transfer data
Name: Tom Z
Date: 1/13/2009 8:56:13 AM
Comment:
zenab,

Creating and consume an asp.net web service is relatively easy with Visual Studio. Here are some links:

http://msdn.microsoft.com/en-us/library/twk6asys(VS.80).aspx
http://quickstarts.asp.net/QuickStartv20/webservices/
http://msdn.microsoft.com/en-us/library/8wbhsy70.aspx
http://aspnet.4guysfromrolla.com/articles/062602-1.aspx

Inside a web service, you just write your method like you write a method in a regular class.

To call the web service from another program in Visual studio, what you need to do is to add a WEB REFERENCE to your application (similar to using a class by adding a REFERENCE to your application), and then call the method like you call a method in a regular class.

Hope this helps. Thanks,

Title: how two asp.net webservices transfer data
Name: zenab
Date: 1/12/2009 11:39:35 PM
Comment:
Hi,
kindly tell me any link in which full procedure is given to show how to develop a webservice in asp.net and how both web services transfer data to each other.
Awaiting for your kind response.
Thanks

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.