Chapter 10 — Groups and roles

Chapter 10 — Groups and roles

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Designing groups"]
  N2["10.2 Naming and ownership"]
  N3["10.3 Avoiding nesting complexity"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Designing groups"]
  N2["10.2 Naming and ownership"]
  N3["10.3 Avoiding nesting complexity"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 Designing groups]
    |
    v
[10.2 Naming and ownership]
    |
    v
[10.3 Avoiding nesting complexity]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) design groups from roles; (2) set naming and ownership rules; (3) avoid nested complexity.

10.1 Designing groups

Kai designs groups directly from the role table: role groups such as role-vet and role-nurse, and location groups such as clinic-north-staff. A person's access comes from their role group, while location groups support clinic-specific resources like shared folders. Keeping roles and locations separate avoids creating a group for every combination, such as nurse-east or vet-west, which would multiply quickly as Fernhill grows. Ruth notes that simple, predictable designs are easier for the next IT person to understand. He draws the design on one page that managers can read in a minute.

10.2 Naming and ownership

Every group follows a naming pattern stating its type and purpose, and has an owner who approves membership and confirms it at reviews. The owner of role-vet is the senior vet; the owner of clinic-east-staff is the east clinic manager. Kai writes these rules on one page. Groups without owners drift: nobody removes members, and nobody knows whether the group is still needed. Ownership gives every group a person who answers for it. Kai sends each owner a short note explaining what ownership involves and how long it takes each quarter.

10.3 Avoiding nesting complexity

Directories allow groups inside groups, which can make access hard to trace. Kai finds a chain of three nested groups that gave finance access to a locum vet through a forgotten link. He limits nesting to one level and documents any allowed nesting in the group's description. Tracing access becomes straightforward: a person is in a role group, the role group grants permissions. Simplicity here is a security property, because access that cannot be explained cannot be reviewed. He checks for new nesting each quarter with his scripts.

Worked example

Kai finds a three-level nesting chain granting a locum finance access and flattens it; nesting is limited to one level.

Synthetic case. Groups and findings are synthetic.

Errors and limits

Creating a group for every role and location combination multiplies groups beyond management.

Exercises

• EX028 — Separation reason. Why keep role and location groups separate? Rubric: 3 = avoid a group for every combination;; 2 = combinations;; 1 = colour;; 0 = none.
• EX029 — Nesting finding. What did the nested chain grant? Rubric: 3 = finance access to a locum vet;; 2 = finance;; 1 = vague;; 0 = none.
• EX030 — Nesting limit. What nesting limit does Kai set? Rubric: 3 = one level;; 2 = one;; 1 = vague;; 0 = none.

Synthesis

Role and location groups with owners and shallow nesting keep access traceable.

Continue studying — chapter 10 of 30

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →