Lesson Overview
Every system in the Principality asks the same first question of anyone who arrives at it: who are you, and are you allowed to be here? An account is the answer. It is the digital stand-in for a real person, the thing that lets a service know that the operator at the keyboard is a particular national, holding a particular appointment, entitled to do particular work. A small digital state may run dozens of services, and if each one kept its own private list of who was allowed in, the lists would drift apart, accounts would be forgotten, and people who had left would quietly keep their access. So the Principality does what a sensible small organisation does: it keeps one trusted list of identities in one place, an identity service, and lets that one service sign a person in to many systems. This is single sign-on, and understanding it is the heart of understanding how the estate is held together.
This lesson explains how identity works across a set of systems rather than inside any one of them. It covers the idea of a single identity provider, why signing one account in to many services is both a convenience and a concentration of risk, how accounts are created and, just as importantly, removed when a person leaves or changes role, what a service account is and why a non-human account can be more dangerous than a human one, how an account is tied to a real person and appointment, and how groups and roles let a force manage access for many people without managing each person by hand. It introduces material that CIS 220 · Identity, Access, and Records Security takes much deeper. It is a knowledge-layer lesson: the practical work of provisioning an account, enrolling multi-factor authentication, or running a leaver's checklist is done and signed off in person, under supervision, where the appointment allows it. Learn the shape of the subject here so that when you touch a real account you already understand what it is and what depends on it.
By the end you will be able to explain what an identity provider is and how single sign-on works; describe why central identity is both a convenience and a concentration of risk, and how that risk is reduced; explain provisioning and deprovisioning and why prompt deprovisioning matters; describe what a service account is and why it must be guarded closely; explain why an account must be linked to a real person and appointment; and explain how groups and roles let access be managed at scale under the rule that access follows appointment.
Key Terms
- Identity: the established fact of who someone is to a system. In digital terms it is a person, represented by an account, that a service can recognise and trust.
- Account: the record a system holds for an individual, normally a username and a way of proving the user is who they claim to be. The account is the digital stand-in for the real person.
- Authentication: proving who you are. Answering the question "are you really this account?", usually with a password plus a second factor.
- Authorisation: deciding what you are allowed to do once you have proved who you are. Authentication is the door; authorisation is which rooms you may enter.
- Identity provider (IdP): a single trusted service that holds accounts and answers, for other services, the question "is this really who they say they are?". Zitadel is an example of an OIDC identity provider.
- OIDC (OpenID Connect): a common, open standard by which a service can ask an identity provider to sign a user in and confirm their identity, without that service ever handling the user's password itself.
- Single sign-on (SSO): the arrangement where one account, held by the identity provider, signs a person in to many separate services, so they prove who they are once rather than once per system.
- Provisioning: creating an account and granting it the access its holder needs to do their work. The joining-up step.
- Deprovisioning: removing an account's access, and the account itself where appropriate, promptly when a person leaves or changes role. The leaving step.
- Joiner, mover, leaver (JML): the three moments in an account's life that change access: a person joins, moves to a new role, or leaves. Disciplined access management handles all three.
- Service account: a non-human account that lets one machine or service talk to another automatically, with no person sitting at a keyboard. Powerful, often privileged, and easy to forget.
- Group: a named bundle of accounts, for example "Signals Section" or "Records Officers", used to manage access for many people at once.
- Role: a named bundle of permissions describing what a kind of user may do, for example "read-only viewer" or "records editor". Roles are granted to groups or accounts.
- Least privilege: the principle that an account is given only the access its role genuinely needs, and no more.
- Orphaned account: an active account that no longer maps to a current person or appointment, for example one left behind when someone left the force. A standing risk.
What an Account Really Is
Start with the smallest unit and build up. An account is not the person. It is a record a system keeps that stands in for the person, so that the system can recognise them on return and decide what they may do. When you sign in, two separate things happen, and it helps to keep them apart in your mind.
The first is authentication: proving you are the person the account belongs to. This is the door. You present something you know (a passphrase), and a second factor you have or are (an authenticator code, a hardware key, a fingerprint). Together these convince the system you are genuinely the holder of the account. Cyber hygiene, taught in CIS 201, is mostly about doing this step well: long passphrases, never reused, with phishing-resistant multi-factor authentication on top.
The second is authorisation: once the system believes who you are, deciding what you are allowed to do. This is which rooms you may enter. The same proven identity might be allowed to read records in one service, edit them in another, and be refused entry to a third entirely. Authentication and authorisation are different questions, and a well-run system asks both: it never lets a proven identity do whatever it likes, and it never grants permissions to someone whose identity it has not confirmed.
Hold on to that distinction, because central identity is mostly about doing the first step once and well, in one place, for the whole estate.
One Trusted List: The Identity Provider
Imagine a small force running a dozen services: a records system, a chat and comms server, file storage, a wiki, a mapping server, a few internal tools. Now imagine each service keeping its own private list of usernames and passwords. A new member would need a dozen accounts created by a dozen different hands; a member changing role would need a dozen separate adjustments; a member leaving would need a dozen separate removals, and the day one of those removals is forgotten, a former member keeps a live way in. Twelve lists drift apart, and nobody can answer the simple question "who has access to what?" because the answer is scattered across twelve places.
The Principality avoids this by keeping one trusted list of identities in one service: the identity provider. Its only job is to hold accounts and to vouch for them. When a national wants to use the records system, the records system does not ask for a password itself. It turns to the identity provider and says, in effect, "this person is trying to sign in; please confirm who they are." The identity provider does the authenticating, then tells the service "yes, this is so-and-so, here is who they are." The service trusts that answer and lets them in. This conversation follows an open standard called OIDC (OpenID Connect), and Zitadel is the kind of identity provider that speaks it.
The figure below shows the shape of it: one identity provider in the middle, fanning out to many services.
+-----------------------+
| IDENTITY PROVIDER |
| (OIDC, e.g. Zitadel)|
| one trusted list of |
| all accounts + MFA |
+-----------+-----------+
|
"is this really so-and-so?" | "yes, here is who they are"
|
+-------------+-------------+-+-----------+-------------+
| | | | |
v v v v v
+---------+ +---------+ +---------+ +---------+ +---------+
| Records | | Chat / | | File | | Wiki / | | Mapping |
| system | | comms | | storage | | docs | | server |
+---------+ +---------+ +---------+ +---------+ +---------+
One national, one account, one sign-in -> recognised by every service.
This is single sign-on. The national proves who they are once, to the identity provider, and every connected service accepts that proof. There is one account to create, one to adjust, one to remove. There is one place that can answer "who has access?", and one place to enforce strong authentication for everybody at once. Turn on phishing-resistant multi-factor authentication at the identity provider and every service behind it gains that protection without each one having to build it.
Why This Is Both a Convenience and a Risk
Single sign-on is a genuine convenience, and you should be clear-eyed that it is also a concentration of risk. The two are the same fact seen from two sides.
The convenience is plain. One sign-in, one account per person, one place to set policy, one honest answer to "who can get in." For a small force with no large IT department, this is close to essential. Managing a dozen separate account lists by hand is how mistakes are made, and the worst mistakes in access management are the quiet ones nobody notices.
The risk is the other face of the same coin. Because one account opens many doors, that one account becomes a high-value target. If an attacker steals a national's single sign-on credentials, they do not get into one service, they get into every service that trusts the identity provider. And because the identity provider itself holds the keys to the whole estate, it is the single most important system to protect: if it were compromised, the attacker could potentially impersonate anyone. The convenience of "one place for everything" is exactly what makes "that one place" so valuable to defend.
This is not a reason to abandon single sign-on. It is a reason to protect the identity provider and its accounts far more carefully than any ordinary service. In practice that means: phishing-resistant multi-factor authentication on every account, and especially on any account with elevated access; the strongest available protection on the identity provider itself; close attention to who holds administrative rights over it; good logging so that unusual sign-ins can be detected; and the disciplined provisioning and deprovisioning described next, so that the list of accounts stays honest and small. A concentration of risk that is well guarded is safer than a sprawl of forgotten accounts that nobody can see. The danger is not central identity; the danger is central identity held carelessly.
Provisioning: Bringing an Account Into Being
Provisioning is the joining-up step: creating an account and granting it the access its holder needs. It sounds simple, and the act of clicking "create user" is simple, but doing it well carries real responsibility, because every account created is a new door into the estate, and every permission granted is a room that door can reach.
Provisioning done well follows a few disciplines. The account is created only for a real, identified person, tied to a real appointment (more on that link shortly). It is granted least privilege: only the access the appointment genuinely needs, and no more. A member who needs to read records is not also given the power to edit them; a member who supports one service is not handed the keys to all of them. Strong authentication is enrolled from the start, not bolted on later. And the act is recorded, so that the force can later answer who created the account, when, and on whose authority. Under the Principality's rule that access follows appointment, the question at provisioning time is never "is this person qualified?" but "does this person's appointment require this access?". A certificate earned in this very course does not, by itself, entitle anyone to anything.
Deprovisioning: The Step That Is Forgotten
Deprovisioning is the leaving step: removing an account's access, and the account itself where appropriate, promptly when a person leaves or changes role. It is the most neglected discipline in all of access management, because creating access feels urgent and necessary, while removing it feels like tidying that can wait. It cannot wait.
The danger is the orphaned account: an active account that no longer maps to a current person or appointment. When a member leaves and their account is not removed, a live way into the estate remains, attached to nobody, watched by nobody, and protected only by whatever password the departed member chose and may now reuse elsewhere or, in a bad parting, share. An orphaned account is a gift to an attacker precisely because no one is looking at it. The same harm in smaller form follows a mover: a member who changes role but keeps the access of their old one accumulates permissions far beyond what their current appointment needs, quietly defeating least privilege one move at a time.
The single greatest benefit of central identity shows here. Because there is one identity provider, deprovisioning a leaver is one disciplined act, not a hunt across a dozen services hoping none is missed. Disable the account at the identity provider and every connected service closes to them at once. This is the practical reason the whole arrangement is worth its risks: it makes the most-forgotten task into the most reliable one.
The diagram below shows the full lifecycle, the joiner, mover, and leaver moments that change access.
JOINER MOVER LEAVER
------ ----- ------
person joins, role changes: person departs
appointed to a role new appointment, or appointment ends
| old one ends |
v | v
+-----------+ v +-------------+
| PROVISION | +--------------+ | DEPROVISION |
| create | | RE-PROVISION | | disable now |
| account, | | grant new | | remove access|
| least | | access, then | | at the IdP, |
| privilege,| | REMOVE old | | revoke certs|
| enrol MFA | | access | | and keys |
+-----+-----+ +------+-------+ +------+------+
| | |
v v v
linked to a real access still matches no orphaned
person + appointment current appointment account left behind
The rule throughout: access follows the CURRENT appointment, nothing more.
The mover step is worth a second look, because it is where least privilege is usually lost. The correct order is to grant the new access and then remove the old, never to simply add the new and leave the old in place. A mover handled carelessly becomes, over several moves, an account with sweeping access that matches no single appointment, which is one of the hardest situations for a small force to notice and unwind.
Service Accounts: The Powerful, Faceless Account
Not every account belongs to a person. A service account is a non-human account that lets one machine or service talk to another automatically, with no operator at a keyboard. The records system reaching the database, a backup job signing in to copy data, a monitoring tool checking that a service is alive, the reverse proxy obtaining a certificate: these machine-to-machine conversations need accounts too, and those accounts are service accounts.
Service accounts are necessary, and they are also among the most dangerous things in the estate, for three reasons. First, they are often highly privileged: a service account that lets one system drive another frequently holds broad access, because automation needs to act without a human to approve each step. Second, they are faceless: no person logs in with them day to day, so nobody notices if one behaves oddly, and they rarely have the multi-factor protection that human accounts do, because a machine cannot tap a phone. Third, they are easily forgotten: a service account created for a job that ended years ago can sit live and unwatched long after anyone remembers why it exists, the orphaned-account problem in its most invisible form.
The discipline for service accounts is therefore strict. Each one is created for a single, documented purpose, so the force knows what it is for and could safely remove it. Each is granted least privilege, only the narrow access its one job needs, never broad access "to be safe." Its credential, often a long secret key rather than a password, is stored securely and never pasted into a chat message, a code repository, or an email. The credential is rotated, that is replaced with a fresh one, on a schedule and at once if it might have leaked. And service accounts are inventoried and reviewed like any other, so that none becomes the forgotten faceless door nobody is guarding. Treat a service account's secret with at least the care you would give your own credentials, because it usually opens more than yours does.
One Account, One Person: The Link to a Real Appointment
An account is only trustworthy if it is firmly tied to a real, identified person and a real appointment. This link is what lets the force answer, for any action in any system, the question that records security depends upon: who did this, and were they entitled to? An action taken by an account that maps to no current person is an action no one can account for, which is precisely what an audit, an incident review, or an honest day's work cannot tolerate.
Several disciplines hold this link firm. Accounts are not shared: a shared "team" login that several people use destroys accountability, because the system can no longer tell who actually did a thing, and cannot be deprovisioned for one person without locking out all. Each national has their own account, and each account belongs to one national. Where an account must exist for a machine rather than a person, it is clearly marked as a service account and tied to a documented owner who is responsible for it. And the whole arrangement is anchored in appointment: an account exists because a person holds an appointment that requires it, its access reflects that appointment, and when the appointment ends the account is deprovisioned. This is the same single thread, access follows appointment, that runs through the entire speciality, seen here from the side of identity. An account is not a possession a member keeps; it is access lent for the duration of an appointment, to be returned when the appointment ends.
Groups and Roles: Managing Access at Scale
If a force grew to a few dozen members and the access of each had to be set by hand, service by service and permission by permission, the work would never be finished and would never be right. Groups and roles are how access is managed at scale without managing each person individually.
A group is a named bundle of accounts, for example "Signals Section" or "Records Officers". A role is a named bundle of permissions describing what a kind of user may do, for example "read-only viewer" or "records editor". The power comes from joining the two: rather than granting permissions to people one at a time, the force grants a role to a group, and every member of the group inherits it. The table below shows the idea.
GROUP (who) ROLE GRANTED (what they may do)
----------------------- ----------------------------------------
Records Officers records-editor : read + edit records
Signals Section comms-operator : use chat/comms server
Systems Assistants service-support : support listed services
All Members directory-viewer : read the shared directory
(no standing group) identity-admin : granted to named
individuals only, sparingly
A person's total access = the sum of the roles of every group they are in.
Add a member to a group -> they gain that group's access at once.
Remove them from a group -> they lose it at once.
Two everyday benefits follow. Joining and moving become clean: a new Records Officer is simply added to the Records Officers group and gains exactly the right access, no more and no less; a mover is taken out of the old group and put in the new, and their access shifts correctly in one step. And access becomes legible: instead of staring at a tangle of individual grants, the force can read off who is in which group and what each group may do, which is what makes review possible. A jumble of one-off individual permissions is impossible to audit; a tidy structure of groups and roles can be checked.
A word of care on the most powerful roles. Administrative roles over the identity provider, the ones that can create accounts, change anyone's access, or reshape the groups themselves, are not handed to a standing group. They are granted to named individuals, sparingly, because each one is a person who can open every door. This is least privilege applied to the keys of the estate, and CIS 220 examines it in depth.
In Practice: A Member Leaves the Section
A national serving in the Signals Section has completed their period of service and is leaving the Army. A systems assistant, Corporal Aldren, holds an appointment that includes running the joiner-mover-leaver checklist at the identity provider, and is rostered to handle the departure. This is a leaver, the most safety-critical of the three JML moments, and the one most often fumbled.
Aldren does not start by deleting things at random across a dozen services, the very scramble that central identity exists to prevent. There is one trusted list, so there is one place to act. At the identity provider, Aldren first disables the leaver's account rather than deleting it outright, which immediately closes every connected service to that person, the records system, the comms server, the file storage, all of them, in a single act, while preserving the account record so the force can still see what that account did in the past. With the live access shut, Aldren works through the rest of the checklist: removing the leaver from every group, so no role is inherited any longer; checking for any service account the leaver was the named owner of, and reassigning its ownership rather than leaving it orphaned; and ensuring the leaver's per-user certificates and keys, the kind of credential issued for secure tools, are revoked, because a disabled account does not by itself cancel a certificate already in someone's hands. Each step is recorded, so the force can later confirm the departure was handled in full.
Aldren then does the small thing that separates a disciplined force from a lucky one: a check for orphaned accounts. Is there anything still active that no longer maps to a current person? The leaver's account is now disabled and grouped to nothing, so it is no orphan. The service account is reassigned, so it is not faceless and unowned. Nothing has been left behind. What would have been a dozen anxious, easily-missed removals across a dozen systems has been one clean, recorded, reliable act, because the Principality keeps one identity in one place. That is single sign-on earning its risk: the same concentration that makes the identity provider precious to guard is what makes a leaver's access vanish completely in a single disciplined step.
Check Your Understanding
- Explain the difference between authentication and authorisation, and state which of the two single sign-on chiefly performs in one place for the whole estate.
- Single sign-on is described as both a convenience and a concentration of risk. Explain how one fact, "one account opens many doors", produces both, and give two ways the risk is reduced in practice.
- What is a service account, why can it be more dangerous than a human account, and name two disciplines that keep service accounts safe.
Reflection (write a short paragraph): Provisioning an account feels urgent and necessary; deprovisioning a leaver's account feels like tidying that can wait. Reflect on why the Principality cannot afford to treat deprovisioning as the lesser task, and what an orphaned account, attached to nobody and watched by nobody, would mean for a small, non-territorial state whose whole existence rests on its protected systems.
Summary
- An account is the digital stand-in for a real person; authentication proves who you are, authorisation decides what you may do, and the two are distinct questions every good system asks.
- An identity provider (an OIDC provider such as Zitadel) keeps one trusted list of accounts and vouches for them, so one account signs a person in to many services. This is single sign-on.
- Single sign-on is both a convenience (one account, one place to set policy, one honest answer to "who has access?") and a concentration of risk (one account opens many doors, and the identity provider becomes the most important system to protect). The answer is to guard it well, not to abandon it.
- Provisioning creates an account with least privilege, tied to a real appointment; deprovisioning removes access promptly when a person leaves or changes role. The joiner, mover, leaver lifecycle covers all three, and a forgotten leaver becomes a dangerous orphaned account.
- Service accounts are non-human, often highly privileged, faceless, and easily forgotten; each needs a documented purpose, least privilege, a securely stored and rotated secret, and regular review.
- An account must link to a real person and appointment; accounts are not shared, and access follows appointment, not qualification.
- Groups and roles let access be managed at scale and reviewed honestly; the most powerful administrative roles are granted to named individuals, sparingly.
- This lesson is the knowledge layer. Hands-on provisioning, multi-factor enrolment, and leaver checklists are practised and signed off in person, under supervision, where the appointment allows.
Related study: CIS 201 · Digital Security and Cyber Hygiene (strong passphrases and multi-factor authentication, the everyday side of protecting an account); CIS 220 · Identity, Access, and Records Security (which deepens identity, groups and roles, service accounts, and the conduct of administrative access introduced here); CIS 310 · Cyber Incident Response and Continuity (responding when an account or the identity provider is compromised); SIG 220 · Communications Security and Digital Discipline (the shared disciplined, defensive mindset); PME 210 · Records and Orders (accountability and who did what); and HCR 220 · Emergency Preparedness and Civil Resilience (continuity of the systems identity protects).
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia