Sources of truth

Who knows best?

Before Dana Okafor's first day on Monday 2 November, Harbor's identity system already knows a good deal about Dana. It knows Dana's legal name, job title, department, manager, site, and start date, because HR recorded them when Dana accepted the job offer. It does not know Dana's mobile number until Dana adds it to the staff profile during the first week. It knows Dana's email address only because it created that address itself, following the clinic's naming rules.

Each of those facts has a natural home. HR knows Dana's job and start date because hiring Dana was HR's work, and because HR's records drive pay, mistakes in them tend to be noticed. Dana knows Dana's own mobile number better than anyone. The email address exists because the clinic's naming rules produced it, so those rules are the authority on it. Nobody would ask Dana to confirm the start date by typing it into a form, or ask HR for Dana's mobile number.

Establishing an identity suggested a question to ask about any piece of identity information: who supplied it, what was checked, and why should this system rely on it? An organization can answer that question once for each attribute, write the answer down, and build its systems to follow it.

Authoritative sources

An authoritative source is the system an organization designates as the place where a particular fact is decided and recorded. Other systems may hold copies, but when a copy disagrees with the authoritative source, the copy is wrong, and changes are made at the source first.

For employees, Harbor's authoritative source is the HR system. It holds each employee's legal name, employee number, job title, department, manager, site, start date, end date, and employment status. For people who are not employees, it is the contractor register kept by the medical staffing office. Locum physicians, students on placement, and supplier engineers are recorded there, each with a register ID, a sponsor who vouches for them, and contract start and end dates. Dr. Lee Moreau's entry, C2291, names the emergency department's medical director as sponsor, and the register is where the contract's end, Friday 27 November at 18:00, is recorded and, if it ever changes, changed.

The identity system reads both sources. It keeps one identity per person, takes the facts each source owns, and passes them on to the staff directory and the applications. Facts start at their source and travel outwards.

It might seem simpler to make the staff directory the source of everything. IT already edits it, and every application reads it. The trouble is that the directory has no way of knowing when things happen. It cannot know that Sam Reyes has accepted a transfer or that a contract has been cut short unless someone tells IT, and then every departure depends on that someone remembering. HR, by contrast, cannot pay people without knowing who works where, so it keeps those records for reasons of its own. Tying access to HR's records means a leaver recorded in HR becomes a leaver everywhere.

Being authoritative is specific. HR is authoritative for an employee's department, not for the employee's email address, and it has nothing to say about Dr. Moreau, who is not an employee. A source is trusted for the facts it owns and for the people it covers.

Owning an attribute

Harbor writes these decisions down in an attribute ownership table. For each attribute the identity system handles, the table names its owner and the one supported way its value changes.

The table does two jobs. It tells the people building integrations which way each value flows, so the identity system reads department from HR and never accepts it from anywhere else. It also tells everyone else where to go to get something fixed. A wrong department is fixed in HR. A wrong contract end date is fixed by the medical staffing office, after the sponsor confirms it. A wrong mobile number is fixed by the person whose number it is.

Everywhere else, these values are copies. Where a system allows it, copies of an attribute owned elsewhere should be read-only. Where a system does not, any edit made to the copy is overwritten at the next synchronization, and that is the design working as intended.

When sources disagree

Sometimes two values for the same attribute reach the identity system, and it needs a rule for which one wins. Precedence rules settle that in advance. The display name is a simple case: if the person has set a preferred name on their staff profile, use it, and otherwise use the legal name from HR. People who appear in both sources need a rule too. When a locum accepts a permanent job, HR's record takes over from the register on the employment start date, so the two sources never both decide the same person's facts on the same day.

Timing matters as well. HR often records changes before they take effect. Sam's transfer to oncology might be entered two weeks ahead, with an effective date of Monday 9 November. The identity system should hold the change until that date. Applying it early would take Sam's pediatric access away while Sam is still working on the pediatrics unit. Applying it late would leave Sam unable to work on the first day in oncology.

The hardest disagreements involve manual edits. Suppose instead that the paperwork for Sam's transfer reaches HR late. Harbor's identity system allows the help desk to override an attribute, a convenience that turns out to do more harm than good:

All names and identifiers in these examples are fictional.

The help desk's edit was right about the facts. Sam really did work in oncology on Monday. It still lost, because precedence follows ownership, not recency and not good intentions. If the most recent edit always won, every copy of every attribute would become a place where access could be changed, by anyone able to edit that copy, with no record at the source. The fix belonged to HR. The help desk's part was to send the problem there and bridge the gap with access that ends by itself.

Recording the overwrite matters too. A synchronization that quietly restores HR's value leaves Sam confused and the help desk puzzled. One that reports a manual change to department overwritten for employee E07731 tells someone that a source and a copy disagreed, which is often the first sign that a source is late or wrong.

Bad data, wrong access

Because access follows attributes, a wrong attribute means wrong access. If HR enters a new billing clerk in the Pharmacy department by mistake, the rules that grant pharmacy access do exactly what they were written to do, and a billing clerk can now use the pharmacy system. Nobody approved that access, and nobody is likely to notice it, because it arrived the same way as everyone else's. A typing error in HR has the same effect as an administrator granting the wrong access.

Missing attributes do quieter damage. An employee with no manager recorded has nobody to approve their requests and nobody to review their access, so requests stall or go to a fallback approver who does not know the person, and reviews pass them by. A contractor with no end date never reaches an end, so their access lasts until someone happens to notice. Harbor's rule for that second case is blunt: no end date in the register, no account.

The identity system can catch some of this as data arrives. It can decline to create accounts for a record that lacks a required attribute. It can hold an unusual change, such as a department that has never existed before, until the owner confirms it. It can send records that fail its checks back to the people who own them. What it should not do is guess. Filling a missing manager with the department head, or mapping an unknown department to the closest match, hides the problem and grants access on the strength of the guess.

Once the right values reach the staff directory, applications read them, and many still do so with a protocol older than most of the applications using it. Continue to Searching a directory with LDAP to read directory names and entries and write the searches those applications send.