Theory: Authorization & Access Control Models
Now that the system knows who you are (6.1), it must decide what you can do. That is authorization, the second A in AAA. Organizations answer the authorization question using an access control model: a consistent rule for who decides access and on what basis. This lesson covers the four core models (DAC, MAC, RBAC, ABAC), the two MAC security models (Bell-LaPadula and Biba), and three related terms (RuBAC, ReBAC, PBAC).
Discretionary Access Control (DAC)
DAC: the resource owner decides who else can access their own resource.
MediCare Plus example: a doctor shares a patient report file directly with a colleague who is covering the case.
| Strength | Watch out for |
|---|
| Simple and flexible for everyday sharing between colleagues | Hard to control centrally: each owner makes their own choices |
| The organization loses a clear overview of who has access to what |
Everyday examples: sharing a document from your own cloud drive, or setting permissions on a file you created.
Mandatory Access Control (MAC)
MAC: the system enforces access based on fixed classification levels. The owner cannot change it.
MediCare Plus example: psychiatric records are classified “Restricted.” Only psychiatry staff with the right clearance can open them, not even other doctors, and the doctor who wrote a note cannot decide to share it.
| Strength | Watch out for |
|---|
| Very strong protection for the most sensitive data | Rigid and slow to change; not practical for most everyday hospital data |
MAC vocabulary
| Term | Role | Meaning | Hospital example |
|---|
| Subject | The actor | The active entity requesting access | A psychiatrist, a nurse, a program |
| Object | The target | The passive resource containing data | A psychiatric record |
| Label | The classification | The sensitivity level assigned to an object | “Restricted,” “Confidential” |
| Clearance | The permission | The authorization level granted to a subject | A nurse cleared to “Confidential” |
Pair them up: labels go on objects, clearances go on subjects. MAC grants access by comparing the subject’s clearance with the object’s label.
Two Security Models Used in MAC
MAC systems follow security models that say exactly how clearance and label are compared. Both use a read rule and a write rule, but they protect different things, so their rules point in opposite directions.
Bell-LaPadula: protects Confidentiality
Bell-LaPadula is afraid of secrets leaking down to lower-level people, so it blocks information from flowing down.
- No Read Up (simple security rule): a subject may not read an object labelled above its clearance.
Example: a general-ward nurse (clearance = Confidential) cannot open a psychiatric record labelled Restricted, because Restricted sits above Confidential.
- No Write Down (star property): a subject may not write information into an object labelled below its clearance.
Example: a psychiatrist (clearance = Restricted) can read Restricted data normally, but cannot copy a summary from the psychiatric record (Restricted) into the general medical record (Confidential), because that would leak Restricted information to everyone cleared only to Confidential.
Biba: protects Integrity
Biba is afraid of dirty, untrustworthy data flowing up and contaminating trusted data, so it blocks information from flowing up. Here the levels are integrity levels (how trustworthy the data is), not secrecy levels.
- No Read Down: a high-integrity subject may not read (rely on) a lower-integrity object.
Example: the hospital’s core treatment-decision system (high integrity) is not allowed to pull data directly from a patient’s consumer fitness-tracker feed (low integrity).
- No Write Up: a low-integrity subject may not write into a higher-integrity object.
Example: the fitness sensor’s data feed is not allowed to write directly into the core EHR (high integrity).
Side by side
The four rules are easy to mix up. Remember: Bell-LaPadula always blocks things moving down (secrets escaping); Biba always blocks things moving up (contamination coming in).
| Bell-LaPadula (Confidentiality) | Biba (Integrity) |
|---|
| Read rule | No Read Up: can’t see secrets above you | No Read Down: can’t trust input from below you |
| Write rule | No Write Down: can’t leak secrets below you | No Write Up: can’t contaminate trusted data above you |
| Allowed | Read at or below your level; write at or above | Read at or above your level; write at or below |
Diagram loads as you scroll.
Common exam mistake: answering “Bell-LaPadula: no read down.” Think about the fear. Bell-LaPadula fears leaks, and reading something below you leaks nothing, so reading down is allowed; reading up (seeing secrets) is what’s blocked. Biba fears contamination, so reading down (relying on dirty data) is what’s blocked.
Role-Based Access Control (RBAC)
RBAC: access is granted based on a person’s job role in the organization. Permissions are attached to roles; people are assigned to roles.
MediCare Plus example: the “Nurse” role can view vitals and update charts. The “Billing Staff” role can view invoices only. A new nurse is simply assigned the Nurse role and gets exactly the right permissions.
| Strength | Watch out for |
|---|
| Easy to understand and manage; matches how organizations already think (job titles) | Role explosion: too many finely split roles (“ICU Night Nurse, Pediatrics, Part-time…”) become hard to maintain over time |
| The most widely used model | A role that is too broad breaks least privilege for everyone in it |
Attribute-Based Access Control (ABAC)
ABAC: access is decided in real time from multiple attributes: of the user (role, department), the resource (which patient, what sensitivity), and the environment (time, location, device).
MediCare Plus example: an ICU nurse may view lab results only for patients under her care, only during her shift, and only from a hospital device.
| Strength | Watch out for |
|---|
| Very flexible; handles complex, context-sensitive rules that RBAC cannot express | Harder to design and manage |
| Avoids role explosion: one rule replaces many narrow roles | Needs a policy engine and careful planning |
Writing an ABAC rule
An ABAC rule reads like an if-statement over attributes:
Allow read on lab result if user.role = Nurse and user.ward = patient.ward and current time is within user.shift and device.owner = Hospital.
Comparing the Four Models
| Model | Who decides | Best fit | Watch out for |
|---|
| DAC | The resource owner | Small teams, flexible sharing | Hard to control centrally |
| MAC | The system (fixed rules, labels and clearances) | Highly sensitive data | Rigid, hard to change |
| RBAC | The job role | Most organizations | Role explosion over time |
| ABAC | Multiple attributes (user, resource, environment) | Complex, context-sensitive needs | Harder to design and manage |
Choosing a model in an exam answer: start from the data and the organization. Lots of staff in clear job roles → RBAC. A small set of extremely sensitive data that nobody should be able to share at will → MAC for that data. Rules that depend on context (which patient, what time, which device) → ABAC (often layered on top of RBAC). Owner-controlled sharing → DAC, which rarely suits regulated data. Real organizations often combine models.
A Few More Terms You May Hear
These build on the four core models:
| Term | Name | Access follows… | Example |
|---|
| RuBAC | Rule-Based Access Control | Fixed if/then rules applied to everyone | Firewall rules: “block all inbound traffic to port 3389” |
| ReBAC | Relationship-Based Access Control | Relationships between people and records | “Only the doctor of record for this patient may edit the treatment plan” |
| PBAC | Policy-Based Access Control | A centrally written policy evaluated by a policy engine | A close cousin of ABAC |
Don’t confuse RuBAC (Rule-based) with RBAC (Role-based). RuBAC rules apply to everyone regardless of who they are (like a firewall rule); RBAC depends on your role.
Worked Examples
Exercise 1
Name the access control model (DAC, MAC, RBAC, ABAC) in each MediCare Plus situation.
- All users with the “Pharmacist” role can verify and dispense prescriptions.
- A doctor right-clicks a report she wrote and shares it with a visiting specialist.
- HIV test results are labelled “Restricted”; only subjects cleared to Restricted can read them, and nobody can change the label.
- A doctor may open a patient’s imaging only if the patient is admitted to her department and she is on a hospital workstation.
Show solution ↓Hide solution ↑
Solution
Ask who decides access in each case.
- The job role decides → RBAC.
- The resource owner decides → DAC.
- The system decides from fixed labels and clearances; the owner cannot override → MAC.
- Several attributes (user’s department, patient’s admission, device) decide in real time → ABAC.
Exercise 2
A hospital uses Bell-LaPadula with levels Restricted > Confidential > Internal. A nurse has clearance Confidential. For each action, say allowed or blocked, and name the rule.
- (a) Read a Restricted psychiatric note.
- (b) Read an Internal staff newsletter.
- (c) Write a summary into a Restricted case file.
- (d) Copy patient details into an Internal (lower-level) ward notice board.
Show solution ↓Hide solution ↑
Solution
Compare the object’s label to the nurse’s clearance (Confidential), then apply the Bell-LaPadula rules: no read up, no write down.
- (a) Restricted is above Confidential → reading up → Blocked (No Read Up).
- (b) Internal is below → reading down leaks nothing → Allowed.
- (c) Restricted is above → writing up cannot leak secrets downward → Allowed by Bell-LaPadula.
- (d) Internal is below → writing down could leak Confidential data to Internal readers → Blocked (No Write Down).
Final answer: (a) blocked, (b) allowed, (c) allowed, (d) blocked. Note that (c) feels odd (“writing into something you can’t read”), but Bell-LaPadula only cares about confidentiality, and upward writes cannot leak anything.
Exercise 3
Now the hospital uses Biba with integrity levels High (core EHR, treatment-decision system) > Medium (lab analyzers) > Low (patient-submitted fitness tracker data). Is each data flow allowed or blocked?
- (a) The treatment-decision system (High) reads blood results from the lab analyzer (Medium).
- (b) The lab analyzer (Medium) writes results into the core EHR (High).
- (c) The core EHR (High) writes a discharge summary into a patient portal copy (Low).
Show solution ↓Hide solution ↑
Solution
Biba rules: no read down, no write up (dirty data must not flow up).
- (a) High reads from Medium = reading down → Blocked (No Read Down). Under strict Biba, the High system must not rely on lower-integrity input.
- (b) Medium writes to High = writing up → Blocked (No Write Up).
- (c) High writes to Low = writing down → Allowed; trusted data flowing to a less-trusted place cannot contaminate anything above.
Final answer: (a) blocked, (b) blocked, (c) allowed. In practice, (a) and (b) show why real systems validate and verify data (for example, a lab result checked and signed off before entering the EHR) before raising its integrity level.
Exercise 4
MediCare Plus’s RBAC system has grown from 8 roles to 140, such as “ICU Nurse Night Shift Ward 3” and “Pediatric Nurse Weekend.” What problem is this, and how would ABAC address it? Write one ABAC rule.
Show solution ↓Hide solution ↑
Solution
Problem: role explosion. RBAC can only express context (ward, shift, weekend) by creating a new role for every combination, so the number of roles multiplies until nobody can manage or review them.
ABAC fix: keep a few broad roles (Nurse, Doctor…) as one attribute, and express the context as other attributes evaluated in real time. One rule then replaces dozens of roles.
Example rule:
Allow a user to read and update a patient’s chart if user.role = Nurse and user.ward = patient.ward and current time is within user.shift and the device is hospital-owned.
Trade-off: ABAC needs a policy engine and careful design, so it is harder to build, but much easier to maintain than 140 roles.
Exercise 5
Identify each MAC term: subject, object, label, clearance.
“Dr. Malee, cleared to Restricted, opens a psychiatric assessment labelled Restricted.”
Show solution ↓Hide solution ↑
Solution
- Subject (active actor): Dr. Malee.
- Clearance (subject’s authorization level): Restricted.
- Object (passive resource): the psychiatric assessment.
- Label (object’s sensitivity): Restricted.
Access is allowed because her clearance (Restricted) is at least as high as the object’s label (Restricted).
Exercise 6
Classify each rule as RuBAC, ReBAC, or PBAC.
- “Only the doctor of record for a patient may sign that patient’s discharge.”
- “Block all connections to the EHR server from outside the hospital network.”
- “All access decisions across EHR, lab and pharmacy are evaluated by one central policy engine against the hospital’s written access policy.”
Show solution ↓Hide solution ↑
Solution
- Access depends on the relationship between the doctor and this patient → ReBAC.
- A fixed if/then rule applied to everyone, like a firewall rule → RuBAC.
- A centrally written policy evaluated by a policy engine → PBAC.