ASP.NET "logon" from external website

Question

Looked but cannot find answer. Not sure exactly what Title ought to be. Hoping for some suggestions from "outside the box". I don't think I can be the only one facing this.

"How can ASP.NET application best "accept" that user authorization has already been performed in a website"?

We have our own ASP.NET (2.0) application. It supports either FBA or Windows Authentication, plus it has its own "username+password" table for "non-Windows" logon. Now we are being asked by customers --- who typically allow their own users on via intranet+Windows logon --- how they can "embed" our app into their own web site and allow their own external Internet customers to access it.

The requirement is that a (external) customer will have logged onto their "member site area" with some username+password authentication. They then want access into our pages "transparently" --- above all else, the end user must not have to resupply any username+password, we must have some way of just "accepting" a passed-in username. We have no way of knowing what the site might have in the way of their own authentication; their own site might be written in, say, ASP, and they are likely to want to make very little effort to change anything.

So, how do I approach this? I realise nothing will be robust; customer will not expect that, but will expect some minimum. For example, if I just tell them "embed URL to our app with ?username=... on it into your app", that would mean anyone external knowing that could get into our app without having been authenticated first by theirs. Putting a password on the URL will hardly help... Is there any advice as to how to address this? Or just "ensure access to web pages is secured in the first place so that users cannot get to your app directly"?

Hope this isn't too long. I know it's a nebulous area, any suggestions would be appreciated.

Answer 1

Tough one, but I would suggest taking advantage of the ASP.NET Membership framework then writing your own Membership provider to interact with their authentication scheme however that is architected, but as you surmised just a URL is not enough from a security standpoint.

Answer 2

Caveat: This probably goes without saying but you should think long and hard about doing this. With the parameters you've given you run the risk of opening your whole system up to anyone who is curious enough to start poking around. I'm not sure how sensitive the nature of your data is, but all it takes is one breach and an angry customer and you could be in a lot of hot water.

If you're not going to ask your customers to do much work on their end your options will be pretty limited.

On the very cheap end of the spectrum you could ask them to link to a page on your site where they pass in some kind of siteId and username in the query string, perhaps, and then you could at least ensure that the referring URL (www.yourcustomersite.com) matches the siteId you'd keep in some table on your end.

The downside of this is that referrers can be spoofed so it wouldn't be a very foolproof solution, but better than nothing.

If you could get your customers to do a tiny bit of work you could at least provide a unique authentication token for each user on their end and require that they send you the token instead of the username. That way you might get ?siteId=yourCustomer&authToken=DKDlas29df9aa01sk instead of a username.

Again, it's not much better but at least makes a brute force attack a tiny bit harder, though not much.

Hope this helps. Good luck!

Answer 3

Have you thought of ticketing? Will they be interested in implementing a web service, to issue a ticket for the user that logs in on their web app. Then, when the user visits your web app you could check his ticket (actually validate it using the web service)... there's a small issue, on how the client's browser saves the ticket...

On the other hand, I see stackoverflow logs in users using OpenID... (the users will need to enter their credentials twice, but they will use the same account) would this be good enough for them?

Answer 4

Hi, please check this blog post first, it's a comprehensive guide to Single Sign On in ASP.net web applications.

Now, regarding the solution presented there for sites in different domains (you can't share the authentication cookie if you are on a completely different domain) I think it has some serious security problems. We did something similar to Andrei suggestion in a website with SSO. When a user logs in to the main site and then wants to visit the secondary site the link to the site holds a ticket (we used a random Guid). The main site stores in a database session information associated to the Guid and the creation time (for ticket expiration). When the secondary site detects a new unauhtenticated user and the ticket it contacts the main site over a web service, the secondary site checks the ticket and returns all the session information it has stored. The other site can then authenticate the user and issue it's own authentication cookie. You'll have to implement something to keep the main site session alive while the user browse the other site so he won't need to login if he is absent for a while. That can be achieved with a persistent cookie or with an iframe in the secondary site pointing to a dummy page in the main site.