In a side conversation at the Orange County APLN meeting last week, we got to talking on the subject of role-based security, and I said that there should be a strict separation between permissions and roles, and between roles and users.  That is, that the programmers should code their security checks only against permissions (never directly against roles or users), and, going the other way, that users should only be assigned roles (never assigned permissions directly).
Yes, this can lead to defining roles that consist of only a single permission, which might seem to be a waste, but it’s not.  Allowing a user to be assigned a permission directly, or allowing a programmer to write a check directly against a role is a classic example of a false economy in software development.  It complicates the code, making alternate paths through the logic to accomplish the same thing.  That’s more code to test, more code to document and explain, more places for bugs to hide, etc. — and, in this case, more places for security holes to creep in, waiting to be exploited.

You can read more on the subject of role-based security in my “Interview with a Sarbanes-Oxley Auditor” from back in August, 2007, where you’ll see that maintaining this strict separation of concerns also makes it much easier to pass an SO audit.