IIS 7 & IIS 8
URL Authorization in IIS 7.0
Last post Mar 14, 2007 06:20 AM by dbaier
Mar 12, 2007 12:45 PM|LINK
I am facing some problem for authorizing static content using URL Authorization module on IIS7.
Our application uses Forms Authentication and all Admin related pages are placed in Admin folder. I have removed the
preconditions for Forms Authentication and Default Authentication so that static content can also be protected.
Following is the section added in web.config file to remove precondition:
<remove name="UrlAuthorization" />
<remove name="DefaultAuthentication" />
<remove name="FormsAuthentication" />
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule,System.Web.Extensions,Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler"/>
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" /> <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"preCondition=""/>
<add name="DefaultAuthentication" type="System.Web.Security.DefaultAuthenticationModule" preCondition="" />
I have two users in my application. One user is in the role of Customer. Other is in the role of Admin.
My requirement is that the content in Admin Folder should be accessible only to the users in role of Admin.
To achive this I have added authorization rules. In applicationhost.config it goes as follows:
<location path="Default Web Site/myApp/Admin">
<remove users="*" roles="" verbs="" />
<add accessType="Allow" users="" roles="Admin" />
This rule should allow users in the role of Admin to access the content in Admin folder. The content in Admin folder includes managed aspx pages and few images. The rule works fine with managed content (*.aspx requests) and the managed content in Admin folder
is accessible only to the users with the role Admin. But when I try to request the image the authorization doesn't work and the request is redirected to the login page.
I cann't find the solution here; why even the Admin role cannot access non ASP.NET content in the Admin folder? Any pointer will be helpful.
Mar 12, 2007 03:29 PM|LINK
I think some other modules (like membership) are needed to make the membership work for non-asp.net content. The best way to do this would be to do
<modules runAllManagedModulesForAllRequests="true /> (I typed attribute name from memory - please check exact spelling from schema)
You do not have to remove re-add modules and once you run a few managed modules for your static file requests, running a few more should not cause any extra perf impact.
Mar 12, 2007 04:11 PM|LINK
there is no "membership" module - and your config looks good to me..where do you get the roles from?
Well - i would not use the "runAllModules" switch unless you need the full asp.net services for your static files - at least in general - in your case Anil is totally right - the admin are won't cause a perf problem....(depending on the number of admins
you have of course ;)
And you don't need the UrlAuthorization module at all if you are using the <authorization> element in <system.webServer>...
Mar 12, 2007 04:21 PM|LINK
Mar 12, 2007 08:06 PM|LINK
Mar 12, 2007 08:27 PM|LINK
Does IIS UrlAuthZ rely on RoleManager - i don't think so. I suppose it is doing a Context.User.IsInrole() - however the roles on the principal got populated....
That's why i was asking in the follow up how he populates the roles...
Mar 13, 2007 05:35 AM|LINK
I tried removing precondition for RoleManager module as indicated by Anil.Now,Authorization is working fine with the non asp.net content also.
I have also removed the entry for URL Authorization module from <system.webserver> section as indicated by Dominick.
Thanks for your inputs.
Mar 13, 2007 04:54 PM|LINK
Again, the safest thing to do is to use the runAllManagedModulesForAllRequests flag rather than trying to remove pre-conditions individually, you are bound to miss one of the required modules. Also, there are intrinsic steps run by asp.net core which do
not appear in the modules section and those may be required for certain scenarios (eg some url/handler rewrite scenarios) and the only way to make them run for non-managed requests is to use the runAll... flag.
Mar 13, 2007 06:36 PM|LINK
could you explain a little more...
ASP.NET consists(ed) of modules and handlers. In IIS7 webcore is driving the pipeline and calls into modules and handlers. The <modules> section and attribute "runAllManagedModules..." naming is very clear - what other code is exactly affected by this setting...if
there would be other code (besides modules) i would consider this as questionable design...
You are right - it may be the "safest" thing just to run all modules - but isn't IIS7 about modularity - i wanna be able to choose which modules should run when...
Also - you said the IIS7 UrlAuthZ is dependent on RoleManager - i can't believe that (though i haven't run any tests against this statement) - This would mean the UrlAuthZ module would call RoleManager.IsUserInRole as opposed to Context.User.IsInRole - can
Mar 13, 2007 08:44 PM|LINK
We call (the equivalent of) Context.User.IsInRole, but asp.net does not populate the roles for forms-auth (so IsInRole would return false) unless the RoleManager module runs. Of course, if you write your own authentication module with your own role-membership
rules, you do not depend on the RoleManager module.
There are execution steps that asp.net runs that are not visible in configuration (eg run code in global.asax), they are registered by asp.net dynamically using GL_APP_RESOLVE_MODULES notification (create a freb log of an aspx request and you will see a
few more implicit modules like these) - the pipeline is still completely driven by IIS core, it is just that the list of runtime modules can be a super-set of the list of modules in configuration and the only way to make them run for all requests is to use
the runAll... flag.