Hello, I am a bit confused about the Authorize filter and what it exactly does.
What I understood is that:
It checks whether the current HttpContext.User has the IsAuthenticated == true
If any role restriction is applied, checks the HttpContext.User.IsInRole(string) method
If any username restriction is applied, checks the HttpContext.User.Identity.Name
What I fail to understand is:
Does the filter check if there is an authentication cookie and assign its contents to the current HttpContext.User if available?
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.
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
cookie.
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.
Marked as answer by ricka6 on Feb 09, 2009 07:33 PM
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?
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
false!
You don't have to set HttpContext.User in your global.asax.cs - it's done automatically in
RoleManagerModule.
Don't forget to click "Mark as Answer" on the post that helped you.
Marked as answer by ricka6 on Oct 14, 2009 12:36 AM
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?
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.
MVCAuthentication
It's all fun and games until someone loses an eye, then it's just fun and games you can't see.
Sgro
Participant
782 Points
352 Posts
Authorize filter explanation
Feb 09, 2009 01:35 PM|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.
Web Developer
IWA Member
levib
Star
7702 Points
1099 Posts
Microsoft
Re: Authorize filter explanation
Feb 09, 2009 05:51 PM|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 cookie.
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.
Sgro
Participant
782 Points
352 Posts
Re: Authorize filter explanation
Feb 10, 2009 08:26 AM|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?
Thanks.
Web Developer
IWA Member
Augi
Contributor
6730 Points
1142 Posts
Re: Authorize filter explanation
Feb 10, 2009 10:50 AM|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 false!
You don't have to set HttpContext.User in your global.asax.cs - it's done automatically in RoleManagerModule.
Sgro
Participant
782 Points
352 Posts
Re: Authorize filter explanation
Feb 10, 2009 11:33 AM|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?
Web Developer
IWA Member
Augi
Contributor
6730 Points
1142 Posts
Re: Authorize filter explanation
Feb 10, 2009 11:41 AM|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.
http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.aspx
Sgro
Participant
782 Points
352 Posts
Re: Authorize filter explanation
Feb 11, 2009 09:15 AM|LINK
Thank you that helped a lot. I think I need to study asp.net Membership a little harder.
Web Developer
IWA Member
Augi
Contributor
6730 Points
1142 Posts
Re: Authorize filter explanation
Feb 11, 2009 09:28 AM|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: http://www.codeplex.com/AltairisWebSecurity (http://www.codeplex.com/AltairisWebSecurity/Wiki/View.aspx?title=Simple%20SQL%20Providers&referringTitle=Home)
It helped me a lot...
jyoung1024
Member
14 Points
37 Posts
Re: Authorize filter explanation
Feb 24, 2009 09:34 PM|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?
Many Thanks,
Joe
jmedia
Member
329 Points
86 Posts
Re: Authorize filter explanation
Oct 13, 2009 02:02 PM|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.
MVC Authentication