Chapter 4 — Data models

Chapter 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 People and accounts"]
  N2["4.2 Groups and systems"]
  N3["4.3 Attributes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 People and accounts"]
  N2["4.2 Groups and systems"]
  N3["4.3 Attributes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 People and accounts]
    |
    v
[4.2 Groups and systems]
    |
    v
[4.3 Attributes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) model people, accounts, groups and systems as related data; (2) distinguish people from accounts; (3) record attributes needed for access.

4.1 People and accounts

A person is not the same as an account. One Fernhill vet may have a directory account, a practice management account and a payroll account. Kai's data model has a table of people, keyed by a staff number from HR, and a table of accounts, each linked to one person and one system. With this link he can answer questions such as which accounts belong to a leaver, which is impossible if accounts are only identified by usernames that differ from system to system.

4.2 Groups and systems

Access is usually granted through groups: vets-all can write clinical records; reception-all can use the booking system. Kai adds a table of groups, with owner and purpose, and a table linking accounts to groups. Another table links groups to the permissions they grant in each system. Together these tables show how a person gets access, through which account and which group, making access explainable rather than mysterious, which matters when a manager asks why someone can see something. Kai checks the tables against two real questions from managers before relying on them.

4.3 Attributes

Some access depends on attributes such as clinic, job role and employment type. A locum vet working at the north clinic for two weeks needs clinical access only there and only for that period. Kai records clinic, role, start date, end date and employment type for each person, taken from HR. Attributes allow rules such as removing locum access automatically on the end date. NIST SP 800-162 describes attribute-based access control, and Kai uses the idea in a simple form suited to a small business.

Worked example

Kai's model has five linked tables, people, accounts, groups, permissions and memberships, plus five attributes per person from HR.

Synthetic case. Tables, people and attributes are synthetic; NIST SP 800-162 is a real source.

Errors and limits

Identifying people only by usernames that differ across systems makes complete leaver removal impossible.

Exercises

• EX010 — Person key. What key links a person's accounts? Rubric: 3 = HR staff number;; 2 = staff number;; 1 = username;; 0 = none.
• EX011 — Group purpose. Why record each group's owner and purpose? Rubric: 3 = to explain how access is granted;; 2 = explain;; 1 = style;; 0 = none.
• EX012 — Locum attribute use. How do attributes help with locum vets? Rubric: 3 = access limited by clinic and removed on end date;; 2 = end date;; 1 = vague;; 0 = none.

Synthesis

Linking people, accounts, groups and attributes makes access explainable and manageable.

Continue studying — chapter 04 of 30

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →