Today I would like to share my views about authoriZation Based Access Control (ZBAC) and how it relates to model-driven security policy automation. There are numerous incarnations of the basic idea: an authorization server issues cryptographically signed tokens for other parties upon request, which are used as an access attribute source when access decisions are made. A standard that can be used to implement authorization tokens is OAuth – however, unfortunately it is often less-than-optimally used to implement what really is a single-sign-on (SSO) authentication assertion token (SAML was originally designed to do that!). The difference is this: SSO is when I authenticate to a central service, which then confirms that I am who I am to whatever service I want to access. ZBAC is more like asking a central service for some access permissions, which can then be used to access a service. A ZBAC token is more like a car key, which gives an authorization to unlock a car to whoever holds the key. While the token should typically be signed and bound to an identity, the holder of the token should be able to issue that authorization (or subsets of it) to other parties (i.e. the car does not care if I lend you my car key – it will still unlock). This is clearly critical for authorization delegation and other necessary features in today’s interconnected IT application chains. Alan Karp et al have written some great reports about the concept and its uses (see “From ABAC to ZBAC”, and "Authorization-Based Access Control for the Services Oriented Architecture").
How does this relate to model-driven security? In fact the main problem model-driven security solves still remains: how can you author the policies that go into the authorization tokens, and how can you maintain a correct policy without a maintenance nightmare. Model-driven security, as implemented for example by ObjectSecurity OpenPMF can do this for both Authorization-Based Access Control (ZBAC) and attribute-based access control (ABAC, e.g. XACML), role/identity-based access control (RBAC/IBAC) in a unified fashion: You author policies in models, and model-driven security policy automation then generates the policy rules that drive (1) ZBAC: the authorization server’s decisioning as to which permissions to add to whose authorization tokens, and (2) ABAC: the policy decision point (PDP) that protects the accessed resource via a policy enforcement point (PEP) based on the policy. In summary, model-driven security can be used as a great mechanism to bring various policy models, such as ZBAC and ABAC, under one unified umbrella. This keeps the maintenance effort and error-potential low.