I have been thinking through authorization scenarios for the current application I am building. The requirements in this application call for a completely extendable, customizable architecture for just about everything. The entire site is themeable (different styles or methods of navigation) and skinnable (variations of color on preexisting theme designs). Another requirement I was tasked with is making the authentication (AuthN) and authorization (AuthZ) mechanism very flexible. While there are only a handful of roles defined today, there maybe more roles added in the future. Herein lays my problem…

I have pretty exhaustively (I think) studied how AuthZ works in the .Net framework. You can do checks configuratively, programmatically, imperatively, and declaratively. (Thanks to DNeimke for defining these examples in his article on 4GuysFromRolla.com ). I probably should preface this with saying I do know there are instances that role based security would be great to use. I am struggling with the maintainability of implementing pure role based security into my actual code.

Programmatic Authorization
Programmatically is a bit better, but not by much in my opinion. This method allows you to check to see if a user is in a specific role by accessing a user object or another object which implements IPrincipal interface. Simple call object.IsInRole(“Administrators”) and it will return true or false.

If Not (User.IsInRole("Public")) And Not (User.IsInRole("Other")) Then
' Display the link
Else
' Don't display it
End If

The problem I see with this (and many of the other options), I am required to code against the set of roles already defined, and not for the possible future roles. I am sure I could come up with a generic function to check if the user is in a collection of roles that I get from a database. I would still have to maintain a page table with a relationship to the roles that would specify which roles belonged to which page. I would rather do the role checking at the database as that point. A simple query could tell me if the user is in a role that has access to a specific page. This also still doesn’t cover task based security which is a more likely scenario for web based applications. For those scenarios you would be forced to use imperative or declarative based authorization.

Imperative Authorization
This method allows you to create an instance of the PrincipalPermission class and demand the permissions before attempting to perform the action. If the current user does not have the permission necessary, a SecurityException will be thrown.

Dim objPermission As New PrincipalPermission(User.Identity.Name, "manager")
Try
objPermission.Demand()
Catch ex As SecurityException
' Don't display it
End Try

I can see how this could be useful in a small application, but you would most likely repeat this code over and over in a larger application. I suppose I would be able to write a sub procedure that accepts a collection of allowed roles and iterate the collection, demanding permission for each role as I go. Again, this doesn’t seem worth it when I can just compare some values in the database and return a simple 1 or 0 in a return value from a stored procedure.

Declarative Authorization
This method involves using attributes to define the authorization requirements for particular methods in a class. The PrincipalPermissionAttribute is used to define which users or roles are allowed access, and what type of security action can be performed.

' Create a method that disables all moderator permissions
' and attach a PrincipalPermissionAttribute to it that issues
' a Demand.
Public Sub DismissModerator()
' logic hereEnd Sub
Try
DismissModerator()
Catch ex As SecurityException
' do something else
End Try

This would be great if my roles were clearly defined and indelible. I do not see how this method would allow me to compensate for database driven roles.

None of the scenarios above are equipped to handle the requirements of my application. I can see if I was using Windows Security how role based security would help. I definitely understand how I can use role based security to my advantage when deploying assemblies into com+ using Enterprise Services. All of these depend on a set of clearly defined, unchanging roles, and maybe that is part of my problem. I am very open to suggestions on how to use the existing framework options for my application (if possible). For now the only method I can see to accomplish my goals are by using the database layer only.

The method I am using to handle authorization with the database, is by storing the page name in a table and relating it to a table of roles that are allowed to access the page. Anytime a request is made for a specific page, I will get the user’s email address out of the FormsAuthenticationTicket, verify that they are a valid user, and then determine through a joined query whether they have access to the page via the allowed roles.

I do not know if this is the best possible way, but I guess that is the question I am posing. I would like to know how other people are conquering this same problem.

Very interesting post. Thanks for sharing your thoughts! I hope that it generates some discussion, because these are such important considerations for .NET apps. Well, and all software today.

I've found that for maximum flexibility in apps I need to do pretty much what you describe in the last part of your post. It can be effective to use the other methods in conjunction with a database approach, but it's also very easy to introduce security holes.

So I generally use declarative security for the big picture, the overall access to the app. Then I usually have some generic code that hooks into the programmatic and/or imperative technique based on the needs of the application. But within those, I put the specifics in a database so that they are easy to modify without compiling code.

One thing to be careful of is overtaxing the database. I would guess that you could make the process more granular than you describe by storing some state so that you don't have to validate the user on every postback. Depending on the site, that could easily overload the system.

Can you make it more granular? Maybe by grouping pages functionally and saving a token in a session variable once the user is authorized for that group of pages? I've seen apps where it really had to be on a page by page basis, but fortunately those are relatively rare.

Don

donkiely, thanks for your reply.

I guess my justification for touching the database every time a page is requested is twofold.

For one, I do not want the ability to cache or store state relating to security in any way, shape or form. To me this is a security risk, even if a very rare one.

Secondly, our application is completely customizable in every way. It is fully themeable, skinnable and every piece of information is editable in some respect in the admin tool. Since the authorization framework I am discussing is for our admin tool, the data perf hit is not such a big deal to me. It will have far less traffic than the sites that are being driven by the data.

Good reasons all. You're being a bit paranoid, which is a very healthy characteristic of a security-conscious developer.

Don

A good friend of mine Rob Chartier(http://weblogs.asp.net/rchartier) came up with a solution that I think might be pretty good. Basically instead of storing the page name in the database, I could mark sections of my code, such as a whole page or a particular method as a "section" of code. I could store the name for this "section" in the database and use a method such as CheckSecurity(currentUser, "SECTIONNAME") to verify if the user has access the particular section of code. This does seem to be more flexible since I can control the section's of code with any boundry I see fit. I was really hoping the ASP.NET team might weigh in on this issue, so if anyone is listening... =)

Wow. That's REALLY getting granular. You really have a need for that? Wow. I hope that it's a maintainable solution. Do you have a link on the blog where he describes it? I didn't see it.

Thanks,
Don