Conventions for evaluating a set of applicable access control (acl) policy statements

‘Access Denied’ or ‘Access Granted’ – Assuming an authenticated request, should it be authorized?

Questions:

What happens when an authenticated request attempts to access a system which controls access to resources based on a set of (potentially conflicting) policy statements?

What are the rules of precedence normally used to decide the result of the aggregated authorization request?

Is it the order of the policies?
Is it specificity of the polciy statement?
Is there a priority/weighting associated with each statement?

Answer:
Typically, it works like this:

All statements in the policy are evaluated against the attributes of the  request: (Principal – who wants to do it, Action – what do they want to do, Resource – on what object). Each statement will evaluate to EXPLICIT_ALLOW, EXPLICIT_DENY or DEFAULT_DENY. These policy statements evaluations are then aggregated into an overall ALLOW or DENY

• Policy statements which do not explicitly pertain to the request attributes ( in terms of the Principal, Action and Resource) evaluate to DEFAULT_DENY
• All the policies are applicable and evaluates to either EXPLITI_DENY or EXPLICIT_ALLOW

Aggregating the result:

if EXPLICIT_DENY.count > 0
return DENY

if EXPLICIT_ALLOW.count > 0
return ALLOW

return DENY;


Adding access control security features to legacy systems

It is not best practice to default any security system to ‘allow all’ in the absence of more explicit policies and then to hone  it with explicit ‘denies’. As an admin, if you make a mistake, it is likely you omitted an explicit ‘deny’ and you’ve left  the system open in a scenario where  you really want it closed. The most secure systems start out with a ‘deny all’ default and open it up incrementally with explicit ‘allows’ over time.

Though the above may seems like stating the obvious, when you’re faced with adding access control based security to a legacy (read: ‘working’) system, backwards compatibility constraints and availability concerns may dictate an ‘allow all’  default.

If this is the case, you should still start with an implementation based on a ‘deny all’ default but you should prime every resource’s/user’s access control with an ‘Allow all’ override. so when resource owners / admins get around to locking down their resources, they are reverting to customizing a secure by default system. Everyone should be happy.