Something really bothers me about the way authorization tends to be done with roles in ASP.NET MVC.
The way it is normally done is that you have a Users table and a Roles table. A User can have many Roles.
Then you decorate your controllers/actions with an authorize attribute saying which roles you want to allow access to the controller/action:
[Authorize(Roles = "Admin")]
public ActionResult AdminOnlyAction()
{
}
The problem with this is that your code is reliant on data within the database.
Obviously you could, at application start, seed your database with the roles needed if they’re not present but there’s still a fragile dependency on the data in the database (e.g. it could be deleted, renamed, etc. etc.).
Having an enum or similar with the Role levels in instead of storing them in the database seems reasonable but still leaves me with a sour feeling.
Is there an elegant alternative which I’ve not hit upon?
1
Obviously you could, at application start, seed your database with the roles needed ...
I would suggest that you should be doing this at installation time, not application start-up. A “user-level” connection probably shouldn’t have permission to make that sort of change anyway.
... there's still a fragile dependency on the data in the database ...
What’s “fragile” about it? It’s no different to [pretty much] every other application ever written that uses a database. If the table structures aren’t set up the way that the application expects, it crashes and burns.
Surely the important issue here is that the relationships between Users and Roles live outside of your code.
The access decorators that you add to your code are static. You mark a method as “Administrators only” and that’s that.
The association of a User with a Role is dynamic. Different people will hold different roles over time; that’s all captured in the database and your code doesn’t change.
First, if you are ensuring they are created — and I’ll disagree with Phill W. here and note that having an “ensure roles” task on startup is a great approach — then they aren’t fragile.
If end users are doing something like manually editing your database then that gets into warranty voiding tampering so things not working would be expected in my book.
Finally, you can build custom attributes that allow you to do more than hardcode Role=Admin. One app we did which was tied to windows had a pretty nifty custom mapping scheme where it had internal groups mapped to external NT groups so the admins weren’t stuck with specifically named groups. This app would also create it’s own NT groups if you’d let it.