We're getting our new MVC project off the ground and are trying to tackle the concerns of authentication and authorization (through Action Filters preferably). Our roles will come across as AD groups (already determined for us) so all we really have to do is read the groups a user is in (from the identity). If you're in one of the groups, you're considered authenticated and proper authorization depends on the action/controller (certain roles can do certain things). Is there a practical benefit towards using a custom Membership Provider? Is there a way I can globally authenticate (since we're using integrated security, there is no login and you can't access any page if you're not auth) so we wouldn't have to put [Authenticate] tags on every controller? Is there an example implementation someone may have a link to?
Is there a practical benefit towards using a custom Membership Provider?
Yes. I found the default membeship provider does not fit in most cases our needs.
Honestly there is more pain working with it than rolling your custom one which is going to be pretty simple.
This doesn't mean you should not use the Identity, just plug into the identity and continue using it.
Is there a way I can globally authenticate (since we're using integrated security, there is no login and you can't access any page if you're not auth) so we wouldn't have to put [Authenticate] tags on every controller?
The best option for me is to apply the [Authenticate] to a base controller and inherit your ones from it.
If course you can write custom HttpHandler/Module or plug into the ControllerFactory.
But it is not worth it.
Another thing is that probably different controllers need different roles, so in this case you do need to apply the [Authenticate(Roles="a,b,c,d")] for each one.
Is there an example implementation someone may have a link to?
Cannot publish the ready examples for you (under NDA). But from what you describe there is really little you need to do. Just apply [Authenticate] attribute and that's it.
proper authorization depends on the action/controller (certain roles can do certain things).
I second Dmitriy's idea of a base controller. Once you authenticate a user against AD, you can put their group name in the cookie, and then read it in the base controller. You could put your group-role mappings in a XML file or something. I do this: in the base controller, I override the OnActionExecuting method, and there I figure out what the action and controller they are requesting is, then I check it against the XML role mappings, which I cache, and if the user is allowed then I let the method proceed, otherwise, I redirect them somewhere.