Dynamically Disable Controls on the Fly

In an earlier post, I mentioned we are starting to look at how to implement role based security in our Smart Client application. Since we are using CAB, it allows us to dynamically load modules on the fly without much effort. We need more control of the UI than just preventing users to see certain parts of the software. Ideally we would want to be able to restrict the UI at a more granular level, the control level. Traditionally, people accomplished this by adding if/else statements to the UI. This method can get messy very fast, and it is very hard to maintain. Before I go on, I would like to thank Chris Holmes (the guy who wrote the first version of the Outlook Explorer bar before Matias Woloski) on sending me so many userful links and ideas regarding this issue.

Irena Kennedy has a great article on how role based security can be accomplished at the control level using attributes. The article can be found here. The article assumes that you are using CAB and AzMan, but the concept is not exclusive to these technologies (It is worth to note that AzMan requires COM interop, so the performance hit has to be considered). It works by decorating the control you want to behavor differently based on user's role. For example, if you want only the manager to have the ability to delete users, you would declare the following attribute on the button:

[Authorization("DeleteUser", "Enabled", False)]

DeleteUser is the operation that is defined in AzMan, and in this case the operation will be associted with the manager role. If the user is not in the role, the button will appear disabled. The code that is acutally doing all the work lives inside of CAB in the RootWorkItemInitializationStrategy.cs. The good thing about this is the logic is isolated in one place, but the down side is we will have to remember to modify CAB code whenever a new version is released.