Is there a way to "sign" an HTTP Post in asp.net?

Question

I have users with accounts on Site A. Site A has been around a long time, and it's expensive (but not impossible) to change its code.

Site B (I'm working on it now!) hosts a brand new web app for the customers of Site A. The Site B app has a list of the usernames from Site A, and maintains preferences and other information about each of those users that pertains to their usage of Site B. Site A and B are different platforms. I think Site A is coldfusion, and Site B is ASP.NET MVC.

I want users to be able to click a link in Site A that logs them into the app on Site B. I was thinking it might work like this:

0) If user tries to go straight to Site B, they just get redirected to Site A to be authenticated.

1) User logs into Site A.

2) Once logged into Site A, they can click a link that takes them to Site B. I was thinking I would do an HTTP Post from Site A to Site B with the username, so Site B knows who is logging in and how to render their pages based on their preferences.

Of course, I don't want any Joe Schmoe to be able to do an HTTP POST to Site B with a username and get to be logged in as that user.

So I was wondering if, using certificates or something, I could make it so Site B is able to know for certain that the POST really came from Site A. Do I need / Can I use certificates for this? Maybe Site A can somehow "sign" its post so Site B can know for sure the post came from Site A?

Or could just a password be enough, where Site A posts a password over SSL along with the username that only Site B knows?

I'm also open to the idea of Site A posting the username and a GUID to Site B, which Site B would then "ask" Site A via a web service if this is indeed a recent and valid GUID that did in fact originate at Site A, but that seems like a trip I can eliminate.

I hope that is descriptive enough. Please feel free to have me explain more. Thank you for your help. :)

Answer 1

You may like to look into OAuth.

Answer 2

Another option would be..

• User signs into site A.

• Site A creates a guid that is associated with this user but will expire in 5 seconds or some short time frame.

• The user is redirected to siteB?UserID=SomId&ConfirmationId=Some Guid

• Site B calls a web service on Site A, passing the UserID and Guid and checks to see if this is a valid redirect. (The web service just returns a true or a false).

This solves your issue of trust, as site B is explicitly querying site A, so site B KNOWS that it is using Site A for authentication, and not just blindly trusting that the confirmation is coming from a redirect from site A.

Also, a Guid is unique enough that it's unlikely to be guessed by hackers, and finally, the expiration makes it so that if a hacker DOES guess the guid, it will likely have expired by the time it's been guessed.

Of course, you'll want this all done over SSL.