A Crash Course in Access Control Models
MAC, DAC, RBAC, RuBAC…
Audience
This article is aimed at those looking to understand access control models for software engineering. It will be conceptual in nature, so a hands-on programming background is not required. You will, however, need a reasonable understanding of basic application design.
Argument
What is access control?
Very broad brush strokes, access control decides who is allowed to access what. For example, we employ it to decide if a user can see a web page.
This is done in the name of keeping sensitive information from being accessed by the wrong people.
We define something looking to perform an action as a subject, and a protected resource as an object. In the above, the user would be the subject and the web page would be the object.
Access control models help us think about how we want to facilitate this process. For example, would we want to permit a user’s access to a file based on their role in the company, or instead use the geographic location they’re making the request from?
We break access control down into the following: authentication, authorization, access approval, audit and management.
Often people scope the concept solely to the ‘access approval’ stage. Admittedly, the focus of the article will be here, but it’s good to have a holistic understanding.
Authentication
This is verifying the subject’s identity.
For end users this could involve a password, key (electronic or physical), one time code, biometric scans, PINs or a number of other things. A combination could be used for multi-factor authentication.
For a machine this could mean having to present a secret.
It’s common to group authentication methods into:
- Something you know, e.g. passwords.
- Something you have, e.g. physical security keys.
- Something you are, e.g. fingerprints.
- Where you are, e.g. within a given IP range.
Authorization
Once the subject has proved their identity, we grant them any privileges they are entitled to.
One way of thinking about this is like visiting a hotel. Once you have shown them your ID you receive your key card, which will let you into some areas of the hotel (e.g. the bar), but not others (staff quarters).
Access Approval
When a subject tries to access an object, using its authorization, it is either approved or denied.
In our hotel analogy, this is like scanning your key card and seeing if you get let in the room. Having to possess something to be allowed in defines a capability-based model.
You could also employ access-control lists (ACL-based models). This is more like going to a fancy party where as long as your name is on the guest list, you’re coming in. All you need to do is authenticate (show your ID)!
Audit
It’s important to make sure we can track which subject accessed which object. This could be as simple as making sure a subject’s actions are sufficiently logged.
Management
Someone needs to be in charge of actually setting the rules before they’re used! This is covered by management.
Access Control Models
In the following section we delineate the different access control models, and their relevant pros and cons. Remember, we’re just focussing on access approval.
Mandatory Access Control (MAC)
Mandatory access control has central administrators who define who can do what. For example, you may have a CEO saying ‘Stephen from accounts can access file one, Mildred from marketing can access file two’ etc.
MAC doesn’t need to work on a file-by-file basis. There may, for example, be an accounting folder, and a marketing folder. Files in each would be exposed correctly.
This can be implemented using a labelling structure. When a subject is created they are assigned labels indicating their clearance. Each object is also labelled, and only subjects with appropriate clearance are allowed access.
The core tenet is no-one outside the administrators can set permissions. Just because I created a file doesn’t mean I would be able to grant you access.
Obviously this keeps things pretty tight! The central body has a lot of power, and knows exactly what everyone can do. Equally, it’s very cumbersome to maintain. It’s common in highly sensitive contexts, such as the military and government.
Discretionary Access Control (DAC)
Discretionary access control is where the owner of the object determines who can access it based on their identity, or the groups they belong to. Compare this to MAC, where a central body does the work.
For example, if I’m in marketing and need to run my presentation past accounts, I can simply grant the relevant people access.
This is a lot more flexible than MAC, but can become a bit of a wild-west when not maintained properly.
Role-based Access Control (RBAC)
RBAC gives permissions based on the role a subject plays in their organisation. For example, if I am in marketing, I may be assigned the ‘marketer’ role.
I don’t necessarily need to be limited to just one. If I work from the London office, I may also be assigned the ‘UK worker’ role. With these I can then get to anything authorized for marketing or UK workers. However, I won’t necessarily be allowed into accountancy files.
Roles can be based on many things, and are generally assigned by administrators. Equally, different roles can be assumed by different subjects at different times.
As we introduce more models it’s easy to get confused between them, so I’ll try to draw out the differences.
Although both this and MAC are controlled by administrators, MAC works on an identity basis (person A can do X), whereas RBAC gives permissions to a role, then the identity assumes it (person A has role 1 which can do X).
This model is useful in larger companies, where maintaining a complex role structure is worthwhile, but less so for smaller ones with more granular access requirements. The main advantage is no longer needing to think in terms of individual identities, but instead being able to make widespread changes to large swathes of subjects.
Rule-based Access Control (RuBAC)
When using RuBAC we have a set of rules determining permissions. For example, we may say ‘anyone can access these files between 9am and 5pm’.
These rules can change depending on context. For example, if a person has failed to enter their password correctly five times, another rule may apply.
There’s no concrete limits on what rules can be based on, just try not to confuse it with the other models! Again, everything is generally controlled by administrators.
The main benefits are how granular control is, and the lack of oversight required (e.g. existing rules will automatically be applied to new subjects).
The main drawback is handling the complexity surrounding using and maintaining rule-bases. What if different rules conflict, and where are the rule computations carried out?
Attribute-based Access Control (ABAC)
Our next access control model is based on attributes of the subject, object, action (what the subject is trying to do to the object), and the context of the interaction.
Examples of attributes include:
- For a subject: job role, seniority, organisation…
- For an object: creation date, last updated, author, file type, creation date…
- For an action: if it’s a read, write, execute…
- For the context: time, location, device…
We may implement a rule saying ‘anyone in marketing can read all budget documents relevant for their quarterly planning’.
The access engine would need to check the relevant attributes such that the subject had marketing, the action was read, the object had budget plus an attribute indicating it was relevant for marketing.
This model can be controlled centrally, or by the file owners themselves.
We can think of attribute-based access control as a flavour of rule-based access control, where the rules take a very specific format.
ABAC is flexible, allows easy onboarding, and granular. However, it’s also also fairly complex!
Identity-based Access Control (IBAC)
IBAC is when a subject is allowed access to an object based on their visual or biometric identity. Once an identity is proven they are checked against an access control list. The most common examples are usernames and passwords (proving your identity by demonstrating access to a secret), or unlocking your phone with Face ID.
The main benefit includes granular control of who can access what. However, with password-based authentication we have issues surrounding their theft. This is circumvented with the introduction of new, biometric-based techniques.
History-based access control (HBAC)
In HBAC we examine a subject’s past security actions to determine if they should be able to access an object.
For example, I am a UK resident, and continually use my bank card in the UK. If a cash withdrawal request suddenly comes from Australia, my bank will most likely deny it.
Previous activities may be examined for the time they were taken, their content, what was accessed etc.
The main advantage is that it requires no extra work from the subject, and is configurable entirely by the administrators. On the other side, it’s not entirely reliable, and requires a backlog of detailed security events.
Combining access control models
Reading through the above, it’s easy to tell some models apart (e.g. discretionary vs mandatory), but more difficult to separate others (e.g. rule-based and attribute-based).
Consulting the literature, the lines do seem blurred. For example, you could augment your attribute-based access control using history-based. If a subject has the right permissions, but their recent usage pattern has been suspicious, then it may well be worth denying their request. This could then be argued to be rule-based.
From what I’ve found, the models are only to aid understanding, they’re not hard and fast rules.
However, whenever you combine them you increase maintenance and usage complexity. Anything you do implement should be done conscientiously.
Breaking the glass!
In certain, extreme circumstances we may want to circumnavigate our access control model. For example, in health services we may want to allow any doctor access to a patient’s personal medical history.
We can either cater to this within our model set up (e.g. a super user role), or by removing access policies all together. It’s worth being conscious of these requirements when designing.
Conclusion
In conclusion we have covered the basic access control models and their relative strengths and weaknesses. We haven’t exhausted the list though! There exist others such as lattice-based access control, graph-based, host-based and many more (a good starting list can be found on Wikipedia here).
