Jim Fleischmann is a security consultant who audits companies for Sarbanes-Oxley compliance [defined]. He and I recently compared notes. As a software developer who has often worked on role-based security systems, it was wonderful for me to get his perspective on where the rubber meets the road. As you might imagine, his feedback was quite different from the usual feedback I’d get through channels (QA bug reports, customer service support tickets, etc.) The following is my recollection of what we covered. I’ll start with Jim’s observations, and then follow up with my own.

I opened the conversation by lamenting on how difficult it is to find information on best practices for role-based security. Jim agreed that there is a dearth of information for this. He suggested that if anything new does surface, I might find it by searching on the phrase “segregation of duties,” that being the overarching concept for which role-based security is just one manifestation.

I next asked Jim what are the most important aspects of any of role-based security system, to him as an auditor. He named four:

• Reporting Capability — The audit stops dead if Jim cannot be provided with hard-copy reports that list: (a) all of the available permissions and their definitions, (b) all of the defined roles with the permissions assigned to them, and (c) all of the active users and their roles.
• Usage Auditing — Next, Jim looks for anything that can tell him whether or not permissions and roles are actually being used. Jim says one of the most common recommendations that come out of his audits is to clamp down on roles and permissions that are not being used. Say, for example, that a user is assigned to a role that is allowed 20 different permissions, but that particular user only ever takes advantage of three of those permissions. Jim’s recommendation would be to define a second role with just those three permissions (or at least a much smaller subset of the 20), and then reassign the user to that new role. Therefore, anything the software can do from an auditing perspective to support the discovery of this kind of information is a boon.
• 100% Role-Based — It’s a red flag to Jim if the software allows a user to be assigned a permission directly (without having to go through a role). That defeats the whole purpose of having roles, he says, and having the roles be meaningful.
• Segregation of Duties Enforced by Mutually Exclusive Permissions — The whole point of role-based security is to give workers access to only the functionality they need to perform their jobs. So, a main focus of any audit is to look for certain tasks that should always be mutually exclusive (e.g. the person processing an order should never be the same person who handles the cash), and then to see that the roles and permissions, as defined, enforce this. All the better if the software actively supports the concept of mutually exclusive permissions, preventing in the first place any one role from being granted both permissions. Furthermore, if the system allows one user to be assigned multiple roles, then the software should also prevent any role combinations that would grant a single user conflicting permissions.

I also wanted to know if Jim had any thoughts on whether or not users should be allowed to be assigned more than one role. Similarly, did he like the idea of having super-roles that are made up of sub-roles, or if that muddled things. Jim did not have an opinion on either. Whichever of these approaches works best for the application, would be fine by him. He did point out that it should be absolutely clear that assigning a user to multiple roles means they are being granted the union of all those permissions, lest someone in administration think they are only granting that user the intersection of them.

Finally, here are a few of my own observations on the practical implementation of role-based security:

• Us Programmers are Lazy — We tend to write code that is wide-open and worry about clamping down on security last, if at all. So, the more we can do as software architects to make security awareness part of the development process, the better. This could mean utilizing code generation and code templates at development time, adding static or dynamic code validation at build time, or taking advantage of aspect oriented programming such as described by Rick Hightower here: www.thearcmind.com/confluence/display/SpribernateSF/ Using+Spring+AOP+to+add+row+level+security +to+Hibernate+or+any+ORM+really.
• Always Code to Permissions, Never to Roles — Application programmers should only code their security checks against permissions, not directly against roles. Roles should be treated only as a mechanism for bundling permissions. For one thing, it simplifies the application code if security checks are always only against permissions. But more importantly, coding directly against a role in effect creates a phantom permission, and it would be all too easy for that aspect of the role, that phantom permission, to go undocumented.
• Hyper Specific Permissions — New permissions should be created at the drop of a hat. Reusing an existing permission for a second purpose is usually wrong. In any event, it’s far easier to merge two permissions that are later determined to be redundant, than it is to split one that is determined to be overreaching.
• Careful Permission Naming — The naming of permissions is hard, but worth every minute spent agonizing over getting them right. It is especially important to ensure that permission names are unique with all other entities throughout the code base. Since permission names are often cited within quoted strings, in XML files, and in database load scripts, most of these occurrences are therefore out of the reach of any of the “safe” refactoring tools that are programmed into modern IDE’s. So, having absolutely unique permission names makes it easier to rely on an ordinary search-and-replace tool.