I am having trouble with forms authentication. The root web.config is setup to deny access to all non authenticated users with a structure like:
Controllers
Folder - Webforms
Folder1 - Webforms
Model
Public Folder - Webforms with web.config to allow public access
Views
web.config with deny
I need to have the home controller public as well, but if I leave the authorize attribute off the root web.config will still block access to the views folder. I want to avoid doing something like below I can avoid it.
Controllers
Webforms
-Folder
-Folder2
-web.config with deny unauthorized users
Views
web.config with public access
Does anyone have any thoughts to make the first directory structure work?
I'm having trouble seeing what the config sections actually look like. Can you edit the post and drop those sections into a Code Sample block (the button with binary in the text editor toolbar).
Is the goal to lock down everything that's WebForms and make the MVC driven bits public?
(Would have just put this in a comment, but I don't have the rep points to leave comments yet.)
[Edit]
For sake of offering something useful, but acknowledging I still don't know the end goal for which bits you want to lock down, on the MVC side, is it feasible for you to use the security attributes within your Controllers? For example, instead of trying to lock actions (or entire controllers) down in the web.config, you can add the [Authorize(Roles="YourRoles")] to the specific actions or to the top of the controller. Pros and cons to this approach, but I like it as I don't have to mess around with the config file much which is something I simply don't enjoy. This is of course assuming you're using the standard ASP.NET membership provider, but even if you've rolled your own, you should be able to accomplish the task in a similar manner with some additional effort. Just a thought...
Related
I'm new to stackoverflow so please bear with me. I haven't found a direct answer to my question.
I am using an MVC web application developed by a third party. There is a particular controller for which I would like to secure viewing of one the items to certain users.
So, for example, the URL a user may hit is:
.../#/MyViews/1
Generally that is fine for all (Windows) authenticated users to see all the MyViews items. However, there may be a few that I would only like one or two users/groups to be able to view. The third party may support that functionality in the future but they don't right now.
I was hoping that IIS authorization would help me out by altering the web.config but I can't get it to work.
I thought I might be able to do something like:
<location path="#/MyViews/234">
<allow users="domain\username" />
</location>
but it doesn't seem to work. It may just be that I can't do it, but I hate having to wait for the third party to provide the functionality.
Am I misunderstanding the capability of the "location" functionality?
Any other potential options to resolve this?
The web.config location settings are meant exclusively for file-based authentication. The values that you put there correspond to physical directories and files on the web server, not to URLs.
MVC does not serve files, it serves resources from controller action methods programmatically. Therefore the web server (via web.config) has no way to override its security. The AuthorizeAttribute is the only sure way to secure an MVC application because it involves locking down the resource (controller action) rather than securing by URL, which would fail if there is an alternate route that can access the same controller action.
The only option you have if you don't have the source code and have no way to plug in your own code is to hope that the 3rd party put some option into the software to configure the security to the level that you need, which would probably involve a custom AuthorizeAttribute subclass that has some settings that can be configured in a configuration file or through a control panel.
I have an xml file with custom routes that I'm creating routes from on Application_Start in Global.asax. Some of those routes require authentication, some don't. Currently I have "location" entries for all those routes in web.config to control authorization.
I wonder whether there is a way to configure locations on application start at the same time I configure routes, so that I don't need to have entries in web.config.
I'm using ASP.NET WebForms .NET 4.0
Try creating your own (or looking at the many open source) sitemap providers. Your sitemap provider can allow you to dynamically change the sitemap nodes based on whatever logic you want and can also allow you to specify roles/users allowed to access each node...
An SO question showing the basic concept is here and a slightly more involved answer is here
That way, you can read your XML to calculate the URLs of the routes, merge it with any existing sitemap definition as appropriate and still get all the ASP.Net security benefits (Security trimming on sitemap, Authorization for URLs, etc.)
This doesn't answer your question directly but I hope this is of some help.
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.
I have an application that uses Forms Authentication to authenticate one type of user. There is a section in this application that needs to be authenticated for another type of user using a different table in the database. The problem happens if the second type of user's session times out, she is taken to the login page defined in the Forms Authentication section of the main Web.Config instead of the login page for the second type of user. I am looking for solutions to this problem. One idea is to create an application in IIS for the section and create a Web.Config for the folder and add another Forms Authentication section. In my experiments, it seems this doesn't work. Am I missing something obvious? Any insights?
IIRC, the authentication works per folder. So you should be able to do it if all of the pages that require the 2nd type of authentication live in a specific sub-folder with it's own config.
Not 100% sure on this, though, so if someone more knowledgeable can contradict me I'll just delete the response.
You may need to double check me on the syntax, but the top level web.config can have any number of tags.
<location>...</location>
Inside you can specify separate config parameters for whatever folder/file you want. Look here for a reference.
EDIT: Apoligies, I neglected to format the code properly
You cannot have an <authentication> section inside of a <location> tag, so you must have the subfolder set up as an IIS (and ASP.NET) application of it's own. So, you should be able to run the subsection on it's own.
I think 500.19 is the "can't read or parse web.config" error - does it have details? You may need to turn on remote errors (or check Event Viewer) to see them. If you're still having issues, post a snippet of web.config.
As an aside - I've never been a fan of nested apps, and would probably prefer having your normal Login.aspx page handle it either with as a MemberOf or perhaps redirecting to a SpecialUserLogin.aspx or something. Nested apps are a PITA to setup and test, IME (for instance - I don't think you can even get it working under Cassini - though you can do 2 separate projects for it, and combine when you deploy).
Yes you can. The Web.config files have a tree-like inheriting arhitecture with override capabilities. Meaning you can modify the settings inside a sub-folder by placing a web.config file there and specifying different configuration settings.
The way I understand this problem, you have two solutions and the first is to look at Roles and the whole Provider Model would be a great place to start. Otherwise, the best bet would be to separate the application into two parts, breaking out the second user type area and then including it back into the main project via a Virtual Directory. Just remember that Virtual Directories inherit their permissions from the parent directories web.config, so you will need to use the <Location>tags to remove authentication for the virtual directory and then within the virtual directories web.config define your new forms authentication. This works well if you need Windows Authentication (NTLM) under Forms Authentication.
We need to replace the menu system in our main ASP.NET application. So naturally we're looking at the ASP.NET SiteMapProvider and Menu controls. However we also need enough security to prevent users from directly entering URLs that they shouldn't have access to. We can do this by putting <location> entries in web.config and securing them individually but that's going to be a PITA to manage across multiple web servers.
Is there a Provider that can be used to, well, provide the equivalent of the <location> entries? I haven't been able to find one, and it's slightly frustrating given the existence of the ConfigurationLocation class.
Alternatively is there a configuration option we're missing in SiteMapProvider that will restrict users from getting to URLs they shouldn't?
Why don't you create rights & profiles to manage wich pages a user can see?
I usually create a user class which implements the IPrincipal security interface. On every request to your application, you check the rights of a particular user and output the SiteMap's nodes allowed for this user.