Identities, accounts, and entitlements

One person, many accounts

Dana Okafor joins Harbor Clinic as a registered nurse on the pediatrics unit. By the end of the first week, Dana exists in at least six places. The HR system has an employee record with Dana's legal name, job, manager, and start date. The staff directory has an entry that other applications read. Patient records, scheduling, and the pharmacy system each have an account, and email and files has a mailbox and somewhere to keep documents.

To Dana, these are all just the clinic's systems. To each system, Dana is something slightly different. Patient records knows the account dana.okafor, the same user name the staff directory uses. Scheduling knows [email protected]. The pharmacy system, which is older, knows an account displayed as "D. Okafor", and little else.

Governance has to keep these apart. An identity, in this section, is the record that represents one person to the organization as a whole. An account is that person's representation inside one system, with whatever name, password, and settings that system uses. What is Identity? made the same point more simply: you are not your account. One identity usually has many accounts, and sometimes more than one in the same system. Jordan Ellis, an IT administrator, has an everyday account in patient records and a separate administrator account, and both belong to Jordan.

Harbor's identity system keeps one identity per person. It reads the HR system and the contractor register, and gives each identity an ID that never changes, such as hc-7f3k2q for Dana. Dana's employee number, E10482, along with Dana's job, department, and manager, comes from HR. The identity system's job is to connect that one identity to every account Dana holds, and to keep track of what each account can do.

What an entitlement is

Accounts matter because of what they allow. Dana's patient records account can read and update the records of pediatric patients. The scheduling account can see the pediatrics rota and swap shifts. The pharmacy account can sign for controlled medication when it is delivered to the ward.

Each system describes these abilities in its own way, so it is worth settling the vocabulary:

• A permission is a single thing an account is allowed to do, such as reading a pediatric patient's record or approving a supplier payment.
• A role is a named bundle of permissions inside one application. In patient records, EHR_PED_RW is a role that bundles reading and updating pediatric records.
• A group is a named set of people or accounts, such as "Pediatrics nurses" in the staff directory. Applications can grant access to everyone in a group at once.

An entitlement is the umbrella word for anything an account is granted in a system: a group membership, a role, a permission, or a specific capability such as "Approve supplier payments" in billing. Governance needs the umbrella word because it has to reason about all of these together. When a manager asks what Dana can do, the honest answer mixes all four kinds, from every system Dana uses.

The kinds still matter when something changes. Removing Dana's EHR_PED_RW role changes one account in one system. Removing Dana from "Pediatrics nurses" might change access in three applications at once, if all three grant something to that group. Knowing which kind of entitlement you are looking at tells you how far a change will reach.

Connecting accounts to people

The identity system can only say what Dana can do if it knows which accounts are Dana's. Linking each account to the identity it belongs to is called correlation. It sounds trivial until you look at what each system stores.

Correlation works best with a stable identifier that both sides hold and that stays the same for as long as the person is at the clinic. At Harbor, that is usually the employee number. The staff directory stores E10482 on Dana's entry, and patient records keeps it in a staff number field, so both accounts link to Dana without any guesswork.

Scheduling has no field for an employee number, so its accounts are matched by email address. That works today, but email addresses change. When someone changes their name, their address usually changes with it, and the scheduling account stops matching anything. Addresses can also be reused. If Dana left and a new nurse with the same name joined later, the old address might be issued again, and a match on email would connect Dana's old account to someone else entirely.

The pharmacy system is weaker still. It holds a login name and the display name "D. Okafor", and nothing else the identity system can compare. A match on display name is a guess: two people can share a name, and the same person can appear as "Dana Okafor", "D. Okafor", and "Okafor, Dana" in three different systems. The identity system flags the pharmacy match until someone confirms it. The lasting fix is for the pharmacy system to record the employee number when accounts are created.

Some accounts match nobody at all. The pharmacy system also has an account called jsmith2, which can order controlled medication. No identity has a matching employee number, email address, or name. An uncorrelated account like this might belong to someone who left years ago, to a contractor who was never entered in the register, or to a test or shared login created by hand. It might also belong to a current employee whose details simply failed to match. Each of those calls for a different response, so an uncorrelated account is something to investigate, not something to delete on sight. Orphaned, dormant, and shared accounts follows that investigation.

Owners and descriptions

Suppose a reviewer is shown that Sam Reyes, a nurse who has just moved to oncology, holds EHR_ONC_RW, and is asked whether Sam should keep it. The name means something to whoever configured the patient records system. To a nurse manager, it is a string of capital letters. The reviewer can approve it because it looks official, or remove it and risk stopping Sam from working. Neither is really a decision.

An entitlement becomes something people can govern when it has three things. It needs an owner, the person accountable for deciding who should hold it. For everything in patient records, that is Morgan Hale, the records manager. It needs a plain description of what it allows, written for the people who request, approve, and review it. And it needs a sensitivity, a rating of how much harm misuse could do, which decides how carefully it is handled.

Harbor records these in an entitlement catalog, a list of every entitlement across its systems with its owner, description, and sensitivity. A few of its rows:

All names, accounts, and identifiers in these examples are fictional.

The catalog changes the reviewer's question. "Should Sam keep EHR_ONC_RW?" becomes "should Sam be able to read and update the records of oncology patients?", and for an oncology nurse the answer is plain. If the reviewer is unsure, the owner column says whom to ask.

Sensitivity decides how much care each decision gets. A high-sensitivity entitlement might need the owner's approval as well as the manager's, an end date, and more frequent review. A low-sensitivity one might be approved automatically, so that people's attention goes to the decisions that matter. EHR_ADMIN sits at the top for a reason: an account holding it can change who may see every record in the system.

Owners also answer questions nobody else can. Someone has to say what an entitlement is for when its meaning is unclear, whether it should be split into something narrower, and when it no longer has a use. An entitlement nobody owns tends to stay in the system indefinitely, granted to each new person because it was granted to the last one.

Seeing the whole picture

With accounts correlated and entitlements described, the identity system can show everything Dana can do, across every connected system, in one place:

Reading across a row tells you how much to trust it. The directory, patient records, and email rows are linked by employee number and will survive a name change. The scheduling row will break if Dana's email address changes. The pharmacy row is a guess until someone confirms it, and until then the clinic cannot be sure the right person holds that pharmacy access.

Reading down the columns serves different people. Dana's manager sees everything Dana can do in one list, in plain words, instead of asking five administrators. Each owner can pick out the rows for their own system. When Dana eventually moves or leaves, the view lists every account that has to change, including the pharmacy account that would otherwise be easy to forget.

The view is only as complete as its connections. Uncorrelated accounts such as jsmith2 appear in nobody's view, which is why they need a list of their own. Systems the identity system cannot read at all, such as a spreadsheet of door codes or a supplier's portal, do not appear either, so Harbor keeps a list of those systems and checks them by other means.

Most of the attributes behind Dana's identity view, and the group that shapes much of Dana's access, sit in a record that many applications share. Continue to What a directory holds to see what that record contains and how applications use it.