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.
Related
For my new website, I am using a custom login.aspx (simply two text boxes username and password with a button). Actually I don't know about authentication modes in ASP.NET. Do I need to specify any mode in my web.config?
What are the security issues related to this?
Any links to articles related to this will be appreciated.
Have a look at ASP.NET Identity. This is the way to handle authentication/authorization in ASP.NET these days.
Start reading the introduction on the asp.net site and a lot of thing will become clear.
Just a login.aspx page will bring you nothing, since there's a lot more involved then just username/password checking. You need to store usernames/passwords, encrypt things, handle cookies (persistent or not), handle autorization, maybe some registration or roles etc etc.
All this things can be done with ASP.NET identity. If it's a new website, in VS2013, Individual User Accounts authentication is on by default when creating a new ASP.NET web project. There's a lot of boilerplate code in the project template to get you up and running...
http://asp.net/identity
Anyway thanks for your suggestion. I am using 'Scrypt' based hashing. Form authentication seems easy but its difficult for me to manage cookies, user tables etc. I use User table for many other purpose also.
This method gives me a good control over everything even if its difficult to get coded.
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 web site that uses forms authentication. the problem is that i have the site installed multiple times on the same production servers because i need to have a few different login pages (based on the domain in this case). after the domain specific login page, the rest of the site is the same. obviously, this requires a lot of maintenance as each new version has to be installed multiple times on the server (with varying the login page in the web.config file).
so i thought is there a way to install the site on 1 folder on the disk, have a web site on the IIS take in all the needed domains and make some http module (or some other solution) in which i could give it a list of domains and the forms authentication for that domain. this way make the login page used by each site change according to the domain while still having only one site to maintain on the server.
Thanks
Dani Avni
I have seen this go a number of ways and a lot of it depends on how you have things setup in IIS.
If all domains are on the same IIS website the most common solution would be to create a httpmodule, or even an actual .aspx page, that loads configuration and based on the requested URL send the user to the right login page. You could even do a "Server.Transfer()" if you want the users URL to stay the same. Then in the web.config you still set a single login page. Just make sure that each other login page allows anonymous users access.
If all domains are separate IIS sites, i would recommend at that point just maintaining different copies of the sites. But the real question is why you need different logins.
My workplace has a couple of web applications that do exactly what you are trying to describe. There are a couple of approaches we have used, depending on the situation.
The more common approach we use is to have all the actual sites on IIS point to the same directory. The logic for the login gets the URL, determines which client site is being requested, and takes that into account on login. The actual login page is the same for all client sites, though, so it's just determining which database to use.
If you want to do anything fancier than that, another approach we have used is to create our own MembershipProvider, at which point you can basically do whatever you want. You should have access to HttpContext.Current if your class is being called by the ASP.NET authentication provider (you would set the membership provider in Web.config to your provider).
I have been Googling a problem that I have with trying to integrate the web application that I am working on with SharePoint 2010.
The web application is a wiki style tool that allows users to log in via forms authentication or WIA against Active Directory and create content for themselves and others.
What we would like to do is to allow a user have a page with the content they have created in our web application mixed in with content that they have living on the SharePoint server. For example, they may want to see a list of documents that they have on the SharePoint server mixed in with some of their content.
To accomplish this, we would like to take the credentials the user has logged into our web application with (for example MYDOMAIN\jsmith) and be able to query SharePoint for the documents of that same user (MYDOMAIN\jsmith) WITHOUT the user being prompted to re-enter their credentials to access the SharePoint server (we are trying to avoid the double-hop problem)
We have come up with some options for how we want to do this, but we are unsure of what the best approach is.
For example, we could
- Have a global user, shared by all users to get information we need from SharePoint. The downside is that we cannot filter SharePoint content to a particular user
- We could store the users credentials when they log in, but that would only work for users authenticating via forms auth and would be a security issue that some users/clients would not like
- Writing a SharePoint extension using WCF to allow us to access the information we need, however we'd still have the issue of figuring out how to impersonate the user we want.
Neither of these options are ideal and in our investigation we came across the Claims Authentication/STS option which seems like it is trying to solve the problem we are having.
So my question is, based on what I have written, is Claims/STS the best approach for us? We have not been able to find much direction on how to use this method to call into SharePoint from a Web Application and pass along the existing credentials.
Does anyone have any experience with any of these issues?
It sounds like you may be overcomplicating the problem. The reason that the user gets asked for credentials twice is that the two parts of the system are on different servers. The easiest solution is probably to implement your custom web app as custom pages/web parts within SharePoint.
If that isn't an option, a smaller amount of code on the SharePoint server (maybe a custom web service) should give you a few more options for impersonating a particular user.
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.