Most technical access control policies today are specified “identity-centric”, a term I use for policies that are specified with the accessor (= the requestor’s identity) in mind. This is the “who?”, “who is accessing?”, “who can do what?” etc. in the question that the policy answers. One of the reasons for doing that is because the information security industry has advocated identity-based access control (IBAC) for two decades or longer by now, involving technology approaches such as identity management (IdM), identity & access management (IAM), federated identity management, single sign-on, role-based access control (RBAC) etc.

After such a long time of advocacy and education, the “collective mindset” of the information security industry has been shaped by the solution, rather than by the problem it is trying to solve. Now that we have deployed the “hammer” (IAM/RBAC), everything looks like a “nail” (identity/role-centric), and the industry keeps on “bolting” access policies onto identity systems. Unfortunately, most information security professionals will agree with the fact that identity-centric access control is not as easy to deploy and manage at scale … if you are actually trying to implement the access policies your organization needs.

Turns out that it is often easier to start stating your access policies with the protected resources in mind (this could be called “Resource-based access control”, ResBAC), and then “bolt” the attributes that are relevant for access to the protected resource onto that resource. The questions now change to “how is the resource to be protected?”, “what is allowed?”, “what are the conditions for access to the resource?” etc. This shift in thinking about and structuring the policy can simplify things because

1. the required protection is often more clear and logical, and thus easier to specify this way
2. you can use richer policies such as – just to name one example – Proximity-Based Access Control (PBAC)
3. the access policy usually gets decided and enforced at the protected resource, so it is easier to distribute resource-based access policies to the place of decisioning/enforcement.

Note that identities still play a critical role, but in the structure of the policy they are one of potentially many attributes (in the context of attribute based access control, ABAC) that determine access to the protected resource.

Model-driven security (MDS) is an ideal approach for implementing resource-based access control (ResBAC) efficiently and effectively. This is because policies can be expressed resource-based in policy models, which are then automatically turned into the matching technical access policy rules for particular interconnected system and applications, and distributed to the protected resources for run-time enforcement. If you are interested in model-driven security product case-studies (as well as FAWs and many educational articles), have a look at ObjectSecurity OpenPMF.