How to authenticate users through domains using ASP.NET and iframe?

Question

I am making ASP.NET websites for a client who wants to make their report page accessible via IFRAME on other Reseller sites. Reseller websites provide the same service with different branding. I need to avoid where I can, requiring them to implement any code on their web server in order to enable this. - therefore, using floating frames

The user will log into the reseller’s website, download the page that contains the IFRAME, which, in turn, downloads the report on the main website. As parameters, we would send the reseller identifier and our username.

We can use SSL server certificates, but not any federated login (like OpenId) -. Business customer choice

The question is, how does the primary site check if the report page is actually being requested by the user who downloaded the page from the reseller? In other words, how to authenticate a user through domains without requiring the reseller to implement the code.

Any thoughts would be greatly appreciated!

Answer 1

I don’t see a satisfactory way to do this without implementing any code on the reseller’s site.

Instead, I would require them to send an HTTPS request from the reseller’s web server to the main web server, passing a unique secret key to identify themselves, as well as the username of their registered user.

After verification on the main site, this key will serve as authentication for the reseller and extension registered by the user.

The response to this request will contain an html fragment string that the reseller can enter on any page.

This fragment will contain an iframe, which, in turn, will download the report for the registered user directly from the main site using its username. The contents of this report will contain a link to the reseller style sheet.

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

In the case when the user's secret key or password is compromised, HTTPS from the browser does not matter.

Answer 2

Your login form may use some javascript to send the login form to a hidden iframe (you cannot use XMLHTTPRequest due to cross-security issues) for each domain that requires login.

Be sure to redirect your iframe back to the original domain or you won’t be able to get login status from the iframe due to cross-domain security.

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

P3P: CP="CAO PSA OUR" 

in the HTTP response headers. Which tells the browser, "I'm not going to do anything wrong, honest."

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

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

Answer 3

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

For example, create an HTML page on your server with an iframe in gmail. While you are authorized against gmail in your browser, you will see your mailbox on this page ...