Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare - they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site. ... What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

The other silver bullet fallacy the RBAC introduces is the idea that objects, subjects, and sessions can be bundled so nicely enterprise wide. People look at their nice org charts and assume that you just plug that into your directory and go. Works great in a domain with hard edges like a call center where discreet groups of people execute the same tasks the same away across many sessions. Not so good once you step above the rote task level. Interestingly "God level" access works well with roles too, but we are not supposed to be building systems with that stuff any more, right?