Nothing really new in this post, but I just ran into some specs defining what needed to be locked down for a project, and it reminded me of a recurring theme that I though would be a good topic to blog about. That usually happens when you find yourself running into the same conversation multiple times.
The basics of an authorization system are pretty simple - you have users and you define what actions users can take on certain "objects". In Windows, for example, those objects happen to be files, folders, registry keys, computers, etc. In any given system, there might be many objects and actions, so for the sake of convenience, you group everything into Roles or Groups. Instead of creating an ACL (access control list - a list of actions a user can take on specified objects) for an individual user, you create ACLs for Roles. It's easier to add users to three roles (with preassigned permissions) than it is to assign 150 permissions to each user.
In some systems, the ACLs are somewhat implicit, and the code simply looks at roles. Each chunk of code looks for certain roles assigned to the user and decides if certain actions are appropriate. While this is certainly easier to implement, it lacks some flexibility and maintainability since it's a bit more hard-coded than actually having a data-driven and explicit ACL. Instead of being able to move permissions around, the most you can do at runtime is move users between roles.
Regardless of whether the ACLs are more implicit or more explicit, the meat of this post is more about "what" to lock down. I'm not sure if this is something taught in a some extremely popular systems design book or something, but it seems like BAs and users naturally drift towards wanting to lock down UI elements. The specs usually read "X users can't see/interact with Y button and Z fields on Screen A". I'm not exactly sure why that irritates me so much, but what you really want in most cases is to restrict actions to more abstract entities, rather than restrict actions to specific UI elements. If you say that X users can't Edit the contact information for Customers, or that Y users can't Deactivate Customers, or that Z users can't Create Customers, then no matter where those interactions occur on a physical UI, the same rules will apply. That's much better than defining permissions on a field-by-field, button-by-button basis. What if there are multiple ways to deactivate a user? For example, a button on Screen A, a maintenance panel on Screen B, and a Menu entry?
Of course, users will still find legitimate reasons for locking down certain UI elements - screens, reports, buttons, etc., but in my opinion, that should always be the exception rather than the rule.
posted @ Monday, January 14, 2008 1:21 PM