Meanwhile, there are clear rules that do not cleanly fit into a user/role system. At its simplest, because I'm a banking customer doesn't mean I can withdraw money from any account even if I have the "canWithdraw" role. Roles often need to be associated with data, which is why we have ACLs that map to entries in our data store. That is, account 1234 has an association that identifies me as its owner and my spouse as an authorized account administrator.
However, some businesses have rules that are more complicated than "is this yours?" or "what permissions do you have on this record?" Instead, they use what you might call "contextual" or "policy-based" security rules. In other words, I might have permission only to withdraw money while I'm within the continental United States. There's no way to express this in an ACL or role-based model. Instead, we've crossed over into policy-based security.
When you can do only some things sometimes
Policy-based security exists quite often in a central repository and relies on central authentication mechanisms (LDAP, Kerberos, and so on). The difference is, instead of maintaining simple roles (such as canWithdraw), each user is associated with a set of policies. The policies are based on a set of attributes about the user, also known as attribute-based access control (ABAC). Those policies cannot be centrally enforced as they are entirely application-dependent.
There are already standards for supporting this, derived in part from defense and other select industries. One such standard is eXtensible Access Control Markup Language (XACML), which allows you to express sets of policies. Enforcement is usually application-based, using some sort of algorithm or rule system. XACML is a pretty comprehensive standard for expression and even handles exceptions likeconflicts in policy or two algorithms enforcing one policy.
Often these ABAC-driven policies, as in the case of RBAC, are based on data rather than application function alone (you can access the schematic for the F-22 only while you're in the United States working for this particular company and a citizen in good standing). One of the first steps in applying policy is often identifying and "tagging" the data to which the policy rules should apply.
Why you should care about advanced security
Clearly, using ABAC-style policies and XACML is a hefty step over RBAC. You should have the motivation to do this, if only to avoid a big, fat $100 million fine. I mean, $100 million here and $100 million there, and before long it adds up to real money.
Also, some organizations have complex rules and ownership of data. As these companies increasingly move to become data-driven and can't analyze everything in place, but instead require centralization, they'll need a system that goes beyond the common RBAC models of today. Moreover, to make that feasible, they'll need tagging and libraries that allow them to apply policies expressed in something like XACML as well as the tools to manage the policy centrally while applying it locally where meaningful.
Sign up for CIO Asia eNewsletters.