How to authenticate users across domains using ASP.NET and iframes?

Question

I am doing an ASP.NET website for a client, who wants to make their reports page available via IFRAME on other "reseller" websites. The reseller websites are providing the same service with different branding. I need to avoid, where I can, requiring them to implement any code on their webserver to enable this - hence using iframes.

A user would log in to the reseller website, load a page which contains an iframe, which in turn loads the report at the primary site. As parameters, we would send the reseller id, and their username.

We can use SSL server certificates, but not any federated login (like OpenId) - a business choice of the client.

The question is, how does the primary site verify that the report page really is being requested by the user who loaded the page from the reseller? In other words, how to authenticate the user across domains, without requiring the reseller to implement code..

Any thoughts would be much appreciated!

Answer 1

I might be missing something, but if the client is authenticated against your server, then it will still be authenticated if you view it through an iframe.

For example, create an HTML page on your server with an iframe to gmail. As long as you're authenticated against gmail in your browser you will see your inbox in that page...

Answer 2

Your login form can use some javascript to post the login form to a hidden iframe (you can't use an XMLHTTPRequest because of cross domain security concerns) for each domain that you require a login for.

Be sure to redirect your iframe back to the original domain or you won't be able to fetch the login status out of the iframe due to cross-domain security.

The final trick for IE support is to flip the evil bit and add

P3P: CP="CAO PSA OUR"

to your HTTP response headers. Which tells the browser "I am not going to do anything bad, honest".

http://support.microsoft.com/kb/323752

http://www.w3.org/P3P/

Answer 3

I see no satisfactory way to do this without implementing any code on the reseller site.

Instead, I would require them to send an HTTPS request from the reseller webserver to the primary webserver, passing a unique secret key to identify themselves, as well as the username of their logged-on user.

Once verified on the primary site, this key would then serve as authentication for the reseller, and by extention, their logged-on user.

The response of this request would contain a html fragment string, which the reseller can inject into any page.

This fragment would contain an iframe, which, in turn, would load the report for the logged-on user directly from the primary site, using their username. This report content would contain a reference to a reseller-specific stylesheet.

With this approach I would say HTTPS is not required in the browser, since both the reseller and their user is authenticated, and if that process happened over HTTPS, we can assume there is no eavesdropper.

In the case where the secret key or the user password got compromised, HTTPS from the browser would make no difference anyway.