views:

191

answers:

2

I was wondering if it is possible to do a RedirectToProvider and have the resulting OpenID provider page displayed in an iFrame. This would make the authentication flow seem a lot more streamlined.

I am using the DotNotOpenID library in ASP.NET MVC (VB).

This next part is sort of a seperate question, but is related.

I am using Ajax.BeginForm for the OpenID sign in form, however the RedirectToProvider fails here for some reason. Does DotNetOpenId not work with MVC and AJAX?

+2  A: 

Question is, would the OpenID provider consider this a security risk or not? If the provider page is inside an IFrame then the surrounding page can have some control over what's happening inside this frame, including an attempt to capture some of the information. It could be a possible exploit risk. Do keep in mind that OpenID providers are very paranoid about these things and might even attempt to break out from such an IFrame or just deny any further login actions. It's a risk that they might not want to take. Is it possible? If it is, I think the answer also depends on the provider.

Workshop Alex
I never actually thought about the security aspect of it! I thought there must be some reason why all the RPs i have seen have not used iFrames. However, i have seen popups used. Does this present a vunerability for the provider as well?
IFrame have the same Same-origin policy as all other content. As long as the browser has no related bugs, all is well.
EFraim
A popup might be a security risk too, but it would run within it's own browser window. With an IFrame around the page, there's a risk that the main page has some JavaScript or other executable code active that's monitoring the user actions. Such a thing is harder to do when the popup is in a separate window.
Workshop Alex
+3  A: 

Yes, DotNetOpenId supports iframes, MVC and Ajax. The OpenIdAjaxTextBox control that ships with the library and is shown used in one of the samples demonstrates this. It does not use iframes to display anything. It uses them with checkid_immediate to attempt implicit login without any user interaction, which is the only iframe-scenario that OpenID intends to support.

The IAuthenticationRequest.RedirectToProvider method internally invokes the ASP.NET Response.Redirect, which itself throws a ThreadAbortException, which might be why it seems to be failing for you, when in fact it's probably working by design, but that design conflicts with what you're probably trying to do.

There are various approaches to take to get what you want done, but as Workshop Alex has already suggested, there is a security concern with hosting the Provider's page in an iframe. It's not that the RP can access or mettle with the content of the iframe, because as EFraim said unless the browser has bugs that would not be allowed anyway. The two problems with it are Clickjacking and that you're training the user to be phished, since he will likely be providing his login credentials to his OP while the RP's URL is in the location bar, which is a bad thing.

And in fact, major OPs now deliberately refuse to work when they are activated within an iframe, so after the work to get it all to behave the way you want, you'd likely be disappointed that most of your customers won't be able to login.

Also as you point out, popup windows, when done properly, can help keep the experience user friendly. You can achieve this a few different ways with DotNetOpenId as well. The ASP.NET controls that come with the library have this feature built in and can be activated by just setting a property on the control. But since you're using ASP.NET MVC (I think), here's how you can do it yourself:

  1. When the user clicks the Login button on your page, rather than POSTing to the current window, have Javascript that opens an appropriately sized popup window at a URL like http://yoursite.com/openid/redirect?id=userSuppliedIdentifier.

  2. Your OpenID controller's Redirect action will read that ID, do an OpenIdRelyingParty.CreateRequest on that ID, and return IAuthenticationRequest.RedirectingResponse.AsActionResult() (MVC style). Note you can pass your own URL to CreateRequest for a returnTo url if you want the OP's response to come back to a different method on your OpenID controller.

  3. When the assertion comes back, your controller should send down javascript that closes the popup window and (as necessary) communicates back to the main window to update its state for the logged in user.

This whole process is completely automated in the ASP.NET controls that DotNetOpenId ships with. It's unfortunate that ASP.NET MVC cannot be made as modularized as ASP.NET web forms so that you don't have to do all this work yourself. Of course, the MVC sample that DotNetOpenId ships with could be made to show how to do popup behavior in a future version. If you want that, file a wish for it.

Andrew Arnott
Problem is that you can never rely on users themselves to be wary of security. For 99.9% of all population, security is an annoying thing that we don't want to even bother with. It's still needed, though.
Workshop Alex
And the security of the browser itself depends on custom client code which might misuse certain vulnerabilities. It might be some JavaScript hack or perhaps a Flash hack. And nowadays we also have Silverlight which also could add more ways to hack an IFrame. OpenID providers should be really careful about these risks, even though there's plenty of legitimate use for it. But providers like MS, Google and Yahoo are big targets for such an identity theft scheme, so they tend to be paranoid in a healthy way.
Workshop Alex
Thanks Andrew, the second (on SO) informative and helpful post you have helped me with! For now, i think i will stick with simply redirecting the user. There is a lot less that can go wrong!