SYSK 119: Granular Role Based Security via an Attribute

Most applications implement role based security to assure that only authorized users have access to restricted application functionality (features). You know the drill—"only certain users can modify salary information in an HR application," or "only managers can view detailed sales reports." There are also more complex examples of authorization, requiring the usage of business rules, such as "Managers have signing authority of $10,000; anything over that amount requires two signatures."

Today, when authorization is done in the UI tier, most developers accomplish it by sprinkling lots of If-Then or IsInRole statements throughout the code to display proper user interfaces. Inspired by the beauty of the ASP.NET server side controls design that allows controls to render themselves differently based on browser capabilities and other context specific attributes, I decided to apply the same logic to security. Why should application developers write any code instead of letting controls (buttons, grids, text boxes) or other plumbing code set the visible, enabled, read only (and so on) properties themselves, based on permissions for the logged in user discovered at run time?

In the previous example, if a logged in user doesn't have permissions to the EditSalary feature on a form that displays Salary data, the 'Salary' textbox control could automatically be rendered as read-only, based on design time settings, with zero lines of code on the form providing the user interface.

If you find this topic interesting, check out my article at MSDN -- http://msdn2.microsoft.com/en-us/library/aa480723.aspx