We're using ASP.NET and IIS 6.0. I realise that the definitions of applications, websites and virtual directories are ill-defined in IIS 6, and changed a lot in IIS 7. However, I'm stuck with IIS 6.0 for now.
We have a single web site defined in IIS, and a number of separate sub-sites in Virtual Directories.
The scheme looks like this:-
http://site.example.com/site1
http://site.example.com/site2
.. etc ..
site1, site2, ... are virtual directories in IIS 6.0, under the "Default Web Site".
I need to use ASP.NET sessions and forms authentication in most of these sites, and I don't want them to share authentication data or session information at all.
Both the mechanisms currently depend on cookies. However, the cookies created by default use the same name, and have a path of "/" in the browser, meaning the sites' cookies will clash with each other.
Without changing the default name for each cookie, how can I enforce separation between my sub-sites? Do I need to change the virtual directories for IIS 6 "Applications"? Or is there some way in code to enforce a more limited scope for the cookies?
Thanks in advance.
For Forms Authentication, you can define the FormsCookiePath property to reflect the virtual directory of each sub site.
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.formscookiepath.aspx
For Session State, I haven't seen anything that can define a path, but you can define different cookie names away from the standard cookieName="ASP.NET_SessionId" value. That way each sub site is looking out for different session cookies.
http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=VS.100).aspx
Related
We have a site that uses Windows Authentication to allow access to the webpages. Most if not all pages are written in classic asp. I recently added a "public" homepage written in asp.net so that users can change their password if they forget it. I tried setting up the homepage as the default in IIS 6, and set all the associated files with that homepage to allow anonymous access.
Problem is, we still get the popup for Windows Authentication. If you type in directly: http://www.website.com/default.aspx the page pulls up no problem. But when you try to navigate to simply http://www.website.com, we keep getting the windows authentication prompt.
I tried removing the global.asa file and an unused global.asax file thinking it was hitting one of these first, but that didn't work. Here are the files that allow anonymous access:
default.aspx
/Homepage -- directory with all code files and other public webpages
web.config
/bin -- folder containing the code generated by VS 2010]
I feel like something that doesn't allow anonymous access is getting accessed first, but can't figure out what it is. Any ideas?
I imagine you have two applications under your Default Website in IIS Manager (IIS 6.0?) One is your classic asp application, with anonymous authentication, and it uses an application pool with "No Managed Code". The other is your ASP.NET application, with windows authentication, which uses an application pool set up for .NET 4.0, or something.
Make sure the Default Website is set for anonymous authentication. Those settings get inherited.
Quite a few years ago, I remember that I struggled with a multiple site under one domain situation, where one of the sites was placed in the root.
At the time I read an authoritative post that clearly explained to me why this was a bad idea, what I remember is the cascading web.config issue being the main reason (forcing you to undeclare conflicting references in child projects that are essentially alien to that project). Henceforth I've always deployed any website in its own virtual path, using a single redirect in the root to point to the default website.
I can't seem to find that authoritative reference anymore and deployment considerations may have changed since then.
What are the pros and more likely, the cons for this scenario? I'm asking because a company I work with frowns on separating the deployments this way and I don't think that's a good idea.
Short answer : isolation. IMO the benefits to host different web site/web applications without isolating them are pointless.
Long answer :
Pros :
Using a single port without specific bindings (ie. aliases) : if you
don't have access to website bindings, its usefull
Rapid-deployment and dynamic web site creation : you can create a new
subsite without declaring it on the IIS side
Sharing settings : apply web site base settings to all subsites
(documents, mime types etc...)
Cons :
Application pool isolation : no identity isolation, no worker process
isolation, no failure/recovery isolation, etc... (time out, memory limit etc...)
AppDomain or lifetime isolation : you'll have to take care of your website AppDomains. If you share the same AppDomain, you'll share the same life cycle : if the
AppDomain is unloaded, all the websites under this AppDomain will go down and reloaded (ie. if you touch an AppDomain web.config)
Architecture isolation : some web application development need some
tunning on the IIS side, if you tune your IIS pool or website just
for one app, its an impact for all the sites. I think about 32-bits and 64-bits setting or wildcard mapping for example.
Code and security isolation : application running in the same worker process and/or AppDomain are less protected against cross-app access/hacks/attacks. You'll have to be more vigilant to ensure that informations from an app cannot be read by another.
Audit : it could be more difficult to audit the web sites activity and failure.
Web application isolation has always be a goal on mutualised environments to protect applications from each other.
Since IIS 7, application pool isolation go further with the "application pool identity" : http://www.adopenstatic.com/cs/blogs/ken/archive/2008/01/29/15759.aspx
I found this article too : http://searchsecurity.techtarget.com/tip/Web-application-isolation.
You should look at SharePoint site collections architecture too. Here's the idea : http://blogs.msdn.com/b/sgoodyear/archive/2011/11/18/9848865.aspx.
The main counterindication for hosting multiple "sites" under one domain (and as such as one "website" in IIS) I can think of would be user identity isolation; a visitor logged in to /site1 would also be logged in to /site2 when you configure e.g. Windows authentication and this is something you might not want.
The same potentially applies for cookies set at the domain level. In IIS a website is a security boundary (for the client as well) and having multiple "sites" in the same domain COULD open you up to security vulnerabilities...
As for placing one "site" in the root and others in subfolders; your appsettings set for the "root site" would cascade to the "subfolder sites"; again this might be a non-issue but it IS a potential security flaw.
I'm working with an ASP.NET application that is currently used only from intranet. The authentication mode for it is integrated Windows security. I now have a requirement that a part of the system should be visible externally with Forms based authentication.
Is it possible to set up authentication in web.config in a way that access to one of the pages goes through Forms while the other pages use integrated auth? Can it be done using a single web.config or do I need a subfolder with its own web.config file?
I know I could create a separate application for the external part but that would mean moving common parts around which ideally I'd like to avoid.
authentification-tag can be located only in Machine.config, Root-level Web.config, Application-level Web.config (source).
I suppose you should create new website in IIS for each authorization mode and add virtual directory that point to source code location. Every website should have custom web.config with authorization-settings.
You can set two MembershipProvider to authenticate users using FormsAuthentication.
For instance, if you want your application to authenticate intranet users with ActiveDirectory, you will select your first MembersipProvider and for the others the second one (you can manage it simply in your login page).
http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx
Or you can implement your own MembershipProvider:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
I've got two ASP.Net applications residing in two different folders on my server:
/Foo <-- this is the standard unsecure application
/Secure <-- this is a separate application that requires SSL by IIS
The problem is that by default, the ASP.NET_SessionId cookie is specified on the domain and is shared between the two applications in different directories. I need the session cookie to be different because I can't allow a hijacked cookie on /Foo to be used to grant access to the /Secure application.
Ideally, I would like each application's cookie to be limited by the cookie Path property. There's apparently no way to do this in .Net out of the box.
As an added headache, even if I write custom code to set the cookie path, I'm fearful that some browsers are case sensitive and won't use the same session cookie for /Foo and /foo, which, depending on how the links are built, can result in multiple sessions in the same application.
Has anyone encountered and overcome this issue?
In .Net 2.0 and above, you can set the "cookieName" attribute of the "sessionState" XML element in your web.config to different values for each of your applications. That will keep them from using the same session ID.
Here's the MSDN reference for this.
Check the icon for your /Secure folder in IIS.
If it has a cog icon then it's a seperate application and the sessions should be different and the app will run in it's own appdomain.
If it's a globe icon then it's a virtual directory and will share the same session as the root site and /Foo.
if you are using forms authentication, then you also need to change the forms cookie in web.config:
<forms name="Foo"...
<forms name="Secure"...
Sounds like they are just in separate virtual directories, but are still in the same Application Pool. If you really want the applications to be separate, try creating another application pool for your /secure app.
I have an IIS website on www.example.com
and a virtual directory at www.example.com/demo/
How can I use the authentication cookie from www.example.com in my virtual directory?
You are looking for a Single Site Login solution. If the article I linked to doesn't help you, there's plenty more on google when you know what to search for ;)
The cookies are shared in the same domain, even shared between applications.
I have used the same cookie to share authentication between a Classic ASP app and a .net app without problems.
Just use the same rules to encrypt or store the cookie.
A solution would be to use integrated authentication. This way the user look up, and authentication authority used, will be the same accost all sites with the servers on the same domain. If you are using something like basic or kerberos authentication then your authentication will not pass between sites even on the same server and possibly between parts of the site that run under different threads, eg a different app pool.
Use session data in asp or cookies to share session information on the same site between pages. Cookies will work even if the virtual folders are shared in a different pool. Just code around the requirements of your virtual directory, in case its shared between multiple sites.
P.S. If you are already using cookies, just have the code in your virtual be the same as what you are using on the other pages.
What are the additional requirements for the virtual? Is it on the same server?