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 DotNetOpenID 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?
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:
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.
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.
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.
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.
Related
I'm new in ASP.net MVC Single Page Application (SPA). I want to design a system that using SPA concepts.
However, I have a bit confusing on how a system consider design in SPA concept? Is it the system URL must always same although we perform many activities or don't have back function (browser) as it always in one page because only render the necessary HTML part? I did googling on this, still have no idea. Does anyone can explain in more simple way?
Thank you.
One of the main advantages of having an SPA is that because you only have one page and you load all the data at once (or make multiple AJAX calls in the background to get data on demand) your application gives an illusion that there is no post back to the server, making your web application seem like an app.
Using SPAs can potentially improve the user experience of your application.Site speed can be improved but you might have to make a user wait a few seconds to load all the initial data.SPA's are great for touch screen appications, such as kiosks and touch based Point Of Sale systems where the navigation is 100% controlled by the SPA.
SPAs also have a lot of disadvantages like implementing the back navigation in your site.In traditional websites this is not a problem but in an SPA you would need to make very clever use of javascript libraries such as Backbone.js or Angular.js to mimic this functionality.Also search engine functionality of public sites and analytics may be a problem.If your are writing a huge enterprise type of application, you may encounter performance problems.
I would stronly recommend reading Disadvantages of Single Page Applications before you make a decision on whether to use them or not.
A SPA can still have multiple different URLs.
In this case, the server that is hosting the application needs to be configured to direct all paths for a URL to the main index.html page.
The index.html page will load the initial part of the SPA, and if it sees there is a path on the URL beyond /, then it will load the "component" for that path.
A "component" as described here might consist of HTML, JavaScript, and request any data that is requested from external APIs.
Angular is a SPA framework that has built-in support for loading components based on registered URL paths. There are other SPA frameworks, as well.
Is it possible to post data from an asp.net application in one domain to another application on a different domain?
I've seen some of the posts where people mention some rather strange ways to inject forms into the response stream, but this seems overkill.
Is it possible and what is the best way to achieve it without hacking Asp.net to death?
Thanks,
Jacques
It's absolutely possible, and pretty easy to do.
Browser posts data to your .net app
Your app uses the HttpWebRequest object to post data to the 3rd party site
3rd party site gives data back to your app or simply accepts post.
Your app responds to the browser with whatever you need.
I have no idea why you would "inject forms into the response stream" or do anything funky like that. Perhaps you could add a bit more about your requirements.
Chris.
If you have access to both applications then the best way is to do it server side.
So make a web service available and consume it from the posting application.
or
Use httpwebrequest server side, see link below.
http://www.netomatix.com/httppostdata.aspx
On the client you could use a library such as http://easyxdm.net/wp/ - though there is a bit of a learning curve.
Here are a couple of links that may help you if you dont want to use the above routes and are prepared to edit your asp.net pages.
http://blog.dmbcllc.com/2009/11/11/asp-net-cross-domain-form-submission/
Cross-Domain Posting in ASP.Net loses Form Fields
I'm working on adding a new webapp to an existing website. I've been directed to write the webapp in ASP.NET. The existing website is written in ColdFusion. For the most part, the ASP.NET webapp is completely stand-alone, but it needs to interact with the ColdFusion code in one important way - if somebody logs in to the ColdFusion site, we don't want them to have to log in again when visiting an ASP.NET page.
When someone logs in to the ColdFusion site, their username is stored in a cookie, along with a login token that can be looked up in our database. My .NET is a little rusty, so I'm having trouble visualizing how the ASP.NET code should use this data. I've already written a simple MembershipProvider that can be used to log in/out out the ASP.NET app using the data in our existing database tables, which are shared with the ColdFusion code.
What I'd like to know is - how can I make sure the ASP.NET app detects the cookies set by the ColdFusion app (I imagine they'd be sent to the ASP.NET pages, since everything is hosted on one domain), and automatically logs the user in using the MembershipProvider and Forms Authentication, using the credentials supplied in the cookie? I'm thinking that putting some kind of cookie check and log in function in the Global.asax file, set to run every page load for every page... but that seems kind of clunky. Also, do people still use the Global.asax file anyway? I had thought there was a more modern method.... Also, how can I manually log someone in using Forms Authentication and a custom membership provider? Currently my code allows the user to log in using the provided login control, but I'm not sure how to log the user in without them having to do anything.
Thanks in advance for any help. Looking over the MembershipProvider tutorials and the MSDN documentation it seems to me like the answer should be staring me in the face, but for some reason I just can't see it. Maybe not enough coffee....
Not sure if this is what you're looking for:
FormsAuthentication.SetAuthCookie("the username goes here",false);
Reference
I'm a CF developer ususally, but we had to do some integration with a .NET application recently and the way we approached it was to keep the CF and .NET sessions separate but ensure that login happened on both so when the user moved from one to the other they were still logged in.
So is there perhaps a way for you to hit your ASP.NET application with a request to login a user when you login using the CF application? Perhaps you could have an iframe on the page that you can load when the CF login is complete that holds a login service for the .NET app?
This way you would not need to worry about one app server reading the other app server's cookies, instead there would be two sets of cookies, one for ASP and one for CF.
Hope that helps!
The way I would approach it, is I would have a specific page that acts as a liaison between the CF and .NET layer. That page would implement your business layer and just check to see if the Cookie is there, if so read it in, do the lookup and login the user or whatever business logic that needs to be done. How would you accomplish the login/authentication, well that’s all based on your login/authentication code.
The only link I can offer is the basic of cookies in ASP.net
http://msdn.microsoft.com/en-us/library/aa289495(v=vs.71).aspx
Edit: found another link that might be helpful.
http://www.aspnettutorials.com/tutorials/network/cookies-csharp.aspx
I have a question that doesn't need any specific answer, just a general direction of what to do. I work for a company that has many sites. Each site requires a login at some point. We have a single Accounts database that all of the sites hit.
One of the requirements for the login system is that if we login on one site, we should automatically be logged in elsewhere.
The way it works right now is that on page load (or init, forget which) at any of our sites (let's say site1.com), it redirects to a "master" site (let's say sitemaster.com). On sitemaster.com there is a web service which checks to see if a cookie exists on sitemaster.com for that user. If it does, it redirects back and lets site1.com know that the user has already logged in (site1.com then creates a cookie for site1.com so we don't have to redirect to sitemaster.com in the future). If the user is not logged in at sitemaster.com, site1.com will then ask the user to login and, on submit, it redirects the user to sitemaster.com which logs them in, creates a cookie under sitemaster.com domain, redirects back to site1.com and lets site1.com know that the user is logged in (which then creates the cookie for site1.com).
On logout a similar method is employed.
Is this the best way of handling universal logins, or auto-logins across multiple sites? Is there a better way of doing things?
Some requirements:
Most of our sites are in .NET 2.0, but there are plans to update them all to .NET 4.0. We want the best method for this auto-login system so if something requires .NET 4.0, that's ok.
The solution should not require javascript (our current solution requires javascript during the login process).
The solution should not require Flash.
It's ok to use iframes, as long as javascript is not requred.
We would like to be able to do AJAX logins (using jQuery) without having the site refresh. The current solution, due to the redirects, prevents us from doing that. (eg: Pop up a modal box asking the user to login, and when they do, the modal box disappears and some content is changed, but no site refresh required). This isn't absolutely necessary, but at the very least we should be able to verify a login using AJAX before any redirecting takes place.
Any articles or suggestions will be very helpful. I also have some questions related to the best way of re-using the auto-login code across sites (varying from ASP.NET 2.0 Forms to ASP.NET 4.0 MVC, but I'll save that for another question).
Bara
At a simple level, your system works very much like OpenID. It might be worth implementing your own internal OpenID provider and save yourself all of the custom work and maintenance/bugfixes etc for a bespoke system. OpenID is supported by many many sites, including stackoverflow.com.
http://openid.net/
and
http://wiki.openid.net/Run-your-own-identity-server
which leads to:
http://www.dotnetopenauth.net/
-Oisin
What you've described is a federated Web Single Sign-On scheme. Ultimately, I'd recommend that rather than rolling your own, you adopted the WS-Federation standard. The advantages being that you're less susceptible to introducing security vulnerabilities and also have the ability to achieve Single Sign-On with applications other than bespoke ASP.NET apps.
Currently, we have a site where almost all the pages fall into some page class that's a subclass System.Web.UI.Page. Generally the subclasses control styling -- headers, footers, etc. -- things displayed on that class of page that we want for all classes.
For one particular class, we check some session variables to see if the user has access to that particular page. If not, they get redirected off and told they don't have access.
I've since implemented a custom role provider and am in the process of updating all my web.config files from to .
The question has arisen: Why not implement the page-based restrictions in the page class instead of implementing a role-provider methodology.
Honestly, when I first considered this topic, it seemed to me there was a clash between and having page classes do the authorization. However, I'm having a difficult time coming up with reasons why page-class based authorization would be a bad idea right now.
If you're able to understand what I'm talking about where we set access (authorization) info during the login process and then use this (session based) information to "authorize" a user to access a page based on the page-class vs using the built-in ASP .NET role provider methodology, I'd appreciate your thoughts on this matter. Especially if you have experience in this area.
Thanks.
Well both ways are possible, IMHO, it comes down to whether you want to use the ASP.NET authorization scheme (allows, denies in the web.config) or code it into the page.
Personally I prefer the configuration approach, as it is more flexible and allows for the pages to inherit from another page class, or use master pages to provide for a common look and feel.