Last post Oct 15, 2009 03:42 PM by jmedia
Feb 09, 2009 01:35 PM|Sgro|LINK
Hello, I am a bit confused about the Authorize filter and what it exactly does.
What I understood is that:
What I fail to understand is:
The fact is that I am used to read the cookie in the Global.asax AuthenticateRequest method, if present create an instance of a custom implementation of IIdentity with an IPrincipal inside, set it to the current HttpContext.User so it can be read and used
during the current request.
But I just saw an application that does not do this step, and still works.
Anyone can give me a detailed explanation of how the Authorize filter works? Thanks.
Feb 09, 2009 05:51 PM|levib|LINK
The three steps you listed above are pretty much the extent of [Authorize]'s logic. The [Authorize] filter is agnostic as to the underlying authentication mechanism; it can be used with FormsAuth, Windows Auth, etc. In the normal course of ASP.NET request
handling, the authentication module runs very early in the request lifecycle. The authentication module is responsible for setting HttpContext.User. In the case of FormsAuth, the authentication module sets HttpContext.User by reading the current authorization
Since MVC simply rides on top of existing ASP.NET infrastructure, this means that the authentication module has already executed by the time the MVC code is called into. We just assume that HttpContext.User has been set appropriately by that module.
Feb 10, 2009 08:26 AM|Sgro|LINK
Ok then, I have one more question. Since the FormsAuth cookie does not provide a way to store user roles, I assume the Authorize Filter does not manage a scenario where it has to set the roles in the HttpContext.User. So, If I am using roles, Do I still
have to set the HttpContext.User in the global.asax?
Feb 10, 2009 10:50 AM|Augi|LINK
If you are using standard role-managing, so using configuration/roleManager element in your
web.config, then you have to specify cacheRolesInCookie="true" on this element. This enables caching roles into cookie (it's different cookie then the cookie used by forms-authentication module) - default value is
You don't have to set HttpContext.User in your global.asax.cs - it's done automatically in
Feb 10, 2009 11:33 AM|Sgro|LINK
I see.. but my role management structure is a bit more complex. I have a Roles table, a Groups table and a Users table. The mappings are:
Users +-------+ Groups
Users +-------+ Roles
Groups +-----+ Roles
(where + means many)
So a User's roles are defined by all the roles applied directly to the user, plus all the roles inherited by all the groups the user belongs to. So I think I have really to do the operation in the global.asax, or do I still have hope to avoid that?
Feb 10, 2009 11:41 AM|Augi|LINK
I'm now using very similar scenario. I wrote my own implementation of RoleProvider that works with my DB. Then you must specify your role-provider class in
web.config only. It's all.
Feb 11, 2009 09:15 AM|Sgro|LINK
Thank you that helped a lot. I think I need to study asp.net Membership a little harder.
Feb 11, 2009 09:28 AM|Augi|LINK
If you will write own Member-, Role and/or Profile- Providers that work against your custom database then "Simple SQL Providers" from this project can be good starting point for you:
It helped me a lot...
Feb 24, 2009 09:34 PM|jyoung1024|LINK
Sorry to jump in on this, but i have been struggling with this of a few days now.
Augi, you mention that if you are using the standard role managing, I assume you are talking about RoleProvider.
I am not using any of the Membership Provider APIs, so I take it I still have to set the current user in global.asax in the AuthenticateRequest?
In that case, if we are just using the "Authorize" attribute (not the locations in web.config), when does the Authenticate_Request get fired?
Oct 13, 2009 02:02 PM|jmedia|LINK
I've been wondering the same thing myself. I'm not using any of the Membership APIs and don't really want to but I'm not sure where I should be setting the details for the HttpContext.User, should I be doing this on by overriding the AuthorizeCore method
in my own attirbute.
I have seen references where people do it in the globax.asax but this can't be right as there will be pages within the site where you don't have to be authorised.
In previous systems we have built we have simply created a base class for our pages that inherited from the Page class and then set the HttpContext.User details in there (from either the cache or the db)
Any input would be greatly appreciated.
Oct 13, 2009 11:02 PM|levib|LINK
AuthenticateRequest is the right place to do this. Note that authentication and authorization are two different steps: the purpose of authentication is to determine who the user is, and the purpose of authorization is to determine whether the current user
has permission to access some resource.
In your scenario, since you're only concerned with telling us who the user is, you want to hook the authentication step. Note the authentication doesn't make any judgments about what a user is or isn't allowed to do. Authentication is concerned only with
verifying the identity of a user.
Similarly, our [Authorize] filter is concerned only with authorization, not authentication. It depends on a different authentication mechanism (such as Windows auth, Forms auth, or your own custom auth) having first been run and having set HttpContext.User
to the correct value. [Authorize] then queries the User property to figure out if it should be allowed to access the protected resource.
Hope this helps!
Oct 14, 2009 09:15 AM|jmedia|LINK
So if I understand what you are saying, I should use AuthenticateRequest in my Global.asax to for example check for cookie and set the httpcontext.user details if my cookie exists and then override AuthorizeCore to check the httpcontext.user's roles etc
to see if they are allowed to access this particular action (using my custom authorize attribute)?
Oct 14, 2009 06:48 PM|levib|LINK
Yes on hooking AuthenticateRequest in Global.asax and setting the User property. You're replacing the
authentication step in the pipeline.
For [Authorize], you shouldn't need to subclass anything or override any method. As long as the User object you set implements things like IsInRole() correctly, the [Authorize] attribute will work just fine with the authentication code that you have written.
Oct 15, 2009 03:42 PM|jmedia|LINK
One thing I have noticed though with hooking into the Authenticate Request method is that on a single page there are numerous requests (I presume for other files such as images etc.) so my code fires every single time, I really only want this to fire once.