Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Identity versus account"]
N2["22.2 Entitlements and roles"]
N3["Lab — Role summary revisited"]
N4["22.3 Reading the model"]
N5["22.4 Attributes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Identity versus account"]
N2["22.2 Entitlements and roles"]
N3["Lab — Role summary revisited"]
N4["22.3 Reading the model"]
N5["22.4 Attributes"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Identity versus account]
|
v
[22.2 Entitlements and roles]
|
v
[Lab — Role summary revisited]
|
v
[22.3 Reading the model]
|
v
[22.4 Attributes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) model identities, accounts, roles and entitlements; (2) distinguish identity from account; (3) build a role model from evidence.
22.1 Identity versus account
An identity is a person or system the council recognises; an account is a record in a particular system that the identity uses. One employee may have a directory account, a payroll account and accounts in several cloud services. Confusing the two causes errors: disabling one account does not remove the person's access elsewhere. Sana's data model has a single identity per person, keyed to the HR record, with every account linked to it. That link is what makes complete leaver removal possible and what the baseline lacks.
22.2 Entitlements and roles
An entitlement is one permission or group membership in one system. Roles bundle entitlements that a job function needs. Following the role-based models of Sandhu and colleagues (1996), Sana models users assigned to roles and roles granted entitlements, with a small set of governed exceptions for individual needs. She builds roles from evidence, grouping entitlements that people in the same job actually hold and use, rather than designing them in a meeting from job titles alone, which tends to produce roles that fit nobody exactly.
Lab — Role summary revisited
"""Summarise synthetic role assignments: members per role and risky permission combinations (stdlib only)."""
from collections import defaultdict
roles = {"clerk": {"view", "payments-raise"}, "clerk-plus": {"view", "payments-raise", "export"}, "approver": {"view", "payments-approve"},
"manager": {"view", "payments-approve", "reports"}, "manager-temp": {"view", "payments-approve", "reports", "export"},
"auditor": {"view", "reports"}, "helpdesk": {"view", "reset"}}
assign = {"u01": ["clerk"], "u02": ["clerk"], "u03": ["clerk"], "u04": ["clerk-plus"], "u05": ["approver"], "u06": ["approver"],
"u07": ["manager"], "u08": ["manager"], "u09": ["manager-temp"], "u10": ["auditor"], "u11": ["helpdesk"], "u12": ["clerk", "approver"]}
members = defaultdict(int)
for u, rs in assign.items():
for r in rs: members[r] += 1
print(f"accounts={len(assign)} roles={len(roles)}")
for r in roles: print(f" {r:13} members={members[r]}")
print("single-member roles:", sorted(r for r in roles if members[r] == 1))
for u, rs in sorted(assign.items()):
p = set().union(*(roles[r] for r in rs))
if {"payments-raise", "payments-approve"} <= p: print("raise+approve:", u, rs)
Run with python3 lab_roles.py. Verified output:
accounts=12 roles=7
clerk members=4
clerk-plus members=1
approver members=3
manager members=2
manager-temp members=1
auditor members=1
helpdesk members=1
single-member roles: ['auditor', 'clerk-plus', 'helpdesk', 'manager-temp']
raise+approve: u12 ['clerk', 'approver']
22.3 Reading the model
Revisiting the synthetic summary from chapter 9 with the data model in mind, Sana sees that clerk-plus and manager-temp are variants that exist only because single people needed one extra permission. In her model these become exceptions attached to the identity, with an owner and an expiry date, rather than new roles. The account holding clerk and approver together breaks a separation rule, so the model includes a constraint preventing that combination. The result is fewer roles, explicit exceptions and rules the system can check automatically.
22.4 Attributes
Some decisions are better expressed with attributes than roles, such as allowing access to a housing case only for staff in the housing department working in the same area office. NIST SP 800-162 describes attribute-based access control for such cases, and Kuhn, Coyne and Weil (2010) discussed combining attributes with roles. Sana's model keeps roles for coarse access to applications and uses attributes, such as department and location from HR, for finer rules inside applications that support them. Attributes are only as good as their source, so HR data quality becomes a security concern.
Worked example
The data model links one identity to many accounts, replaces two variant roles with expiring exceptions, adds a raise-approve constraint and uses department and location attributes for case access.
Synthetic case. The model, roles and attributes are synthetic.
Errors and limits
Treating an account as the person means disabling one account leaves the person's other access untouched.
Exercises
- EX064 — Identity definition. How does an identity differ from an account?
Show marking criteria
Rubric: 3 = identity is the person; account is a record in one system;; 2 = person vs record;; 1 = same;; 0 = none. - EX065 — Variant role fix. How are clerk-plus and manager-temp handled in the model?
Show marking criteria
Rubric: 3 = replaced by owned, expiring exceptions;; 2 = exceptions;; 1 = kept;; 0 = none. - EX066 — Attribute source risk. Why does HR data quality become a security concern?
Show marking criteria
Rubric: 3 = attribute decisions depend on it;; 2 = attributes;; 1 = it does not;; 0 = none.
Synthesis
Separating identities from accounts and combining evidence-based roles, governed exceptions and attributes gives a model the system can enforce.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →