One login, many systems: why central authentication comes first

Count the logins first

A hospital that has been digitalizing for a few years does not run one system. It runs a hospital management system for registration and billing. It runs a laboratory system, usually from a different vendor, often connected to instruments that predate it. There is a pharmacy and stores module, a radiology viewer, something for health insurance claims, a queue and token display in the outpatient hall, an attendance system on a fingerprint reader, and a reporting tool that pushes monthly numbers upward. Add an appointment site and a feedback portal and the count passes ten.

Every one of those arrived with its own user table. Its own password rules. Its own idea of what the word "role" means. The laboratory system thinks a role is a permission on a test group. The billing system thinks a role is a counter. The reporting tool thinks a role is a district.

Nobody planned this. It is what happens when systems are bought one at a time, over years, from whoever won that year's tender.

What goes wrong is boring, and expensive

The failures are not dramatic. They are administrative, and they compound.

• A laboratory technician resigns in Asar. Their accounts are closed in the two systems the department remembers and left open in the other six. Nobody notices, because nobody has a list.
• A staff nurse transfers from the emergency department to the ward. Their new access is granted. Their old access is never removed. After three transfers a mid-career employee has more access than the medical superintendent, purely by accumulation.
• A vendor's support engineer is given an administrator account during go-live. It is still there four years later, with the password that was set in the first week.
• Two people share one account because the second person's request is stuck with an officer who is on leave. From that moment, the audit trail of that system is fiction.
• The password rules differ by system, so staff pick the one weak rule that satisfies all of them, and reuse it everywhere.

Now ask the question an auditor asks, or the question you have to answer after an incident: who has access to what, right now? In an institution with ten separate user tables, that question has no answer. It has ten partial answers, each held by a different person, each out of date.

Roles belong in one place, not in ten

This is the first reason to build central authentication, and it is the one that pays for itself.

When identity is central, a role is defined once and means the same thing everywhere. "Ward in-charge, Surgical B" becomes a single statement about a person, and every system reads it rather than inventing its own version. Granting it is one action. Revoking it is one action, and it takes effect everywhere in seconds rather than in whichever systems somebody remembers.

That single change turns access control from an ongoing clerical burden into a governable process. Joining, moving and leaving become three operations instead of thirty. The person who approves access is the person who owns the role, not whichever vendor's support desk answers first. And because the record is central, "who has access to what" becomes a report you can run rather than an investigation you have to launch.

It also changes what a new system costs. A new application no longer needs a user management module, a password reset flow, a session timeout policy or an account approval workflow, because all of that already exists and it simply asks the central service who the person is. That is weeks of build removed from every future procurement, and one fewer place for credentials to leak from.

A managing body cannot govern what it cannot see

The second reason matters more the further up you sit.

A ministry, a provincial health directorate, a hospital development committee or a board is expected to know what it is responsible for. In practice, when systems are procured department by department and hospital by hospital, nobody at the top has a reliable list of what exists. Systems are commissioned, renamed, abandoned, replaced and quietly kept alive on a machine under a desk. Ask a managing body how many applications hold patient data across its institutions and you will usually get an estimate, delivered with a caveat.

Central authentication produces that list as a by-product, and this is the part that is consistently underestimated. If every system must register with the identity service in order to authenticate anyone, then the identity service holds a live register of every system in the estate: what it is called, who operates it, which institution it serves, how many people use it, when it was last used at all, and which roles it recognises. Nobody has to compile that register, and nobody can forget to update it, because a system that is not registered simply does not work.

From that register, oversight becomes ordinary work rather than a special exercise:

• Estate visibility. A ministry can see every application in use across its hospitals, including the ones nobody reported.
• Dormancy. A system that has authenticated nobody for six months is either dead or is being accessed some other way. Both are worth knowing.
• Concentration risk. If four hospitals depend on one vendor's platform, that is visible before the vendor's contract lapses, not after.
• Access reporting. How many people hold administrative rights over patient data, across the whole estate, becomes a number instead of a guess.
• Onboarding policy. A new system cannot be quietly introduced outside the approved architecture, because it has to be admitted to the identity service to function.

None of that requires the managing body to run the hospitals' systems, or to see clinical data. It requires only that authentication passes through a service the managing body governs. That is a light touch with a large effect, and it is the reason central identity tends to be the first shared component that national health architectures build.

Authentication is only the thin end of it

The third reason is the one most easily missed, because the name of the thing describes only its smallest function. A central identity service answers "who is this person?" But once every system asks that question at one place, that place becomes the natural point to enforce almost everything else you would want to control. Authentication is the doorway. What the doorway lets you do is the point.

Consider what can be decided centrally, once, instead of separately in every application:

• Authorization, not just identity. The service can carry roles, group memberships, department and facility assignments, and issue them to applications as claims. The application stops maintaining its own permission table and starts trusting a statement it can verify.
• Session control. Sessions can be listed and terminated centrally. When a laptop is lost or a member of staff is suspended, one action ends every session in every system, immediately.
• Step-up authentication. Ordinary work needs an ordinary login. Approving a large payment, changing a laboratory reference range, exporting a patient list or opening a colleague's record can demand a second factor at the moment of the action, without every application implementing its own.
• Credential policy in one place. Password length, rotation, lockout, multi-factor enrolment, and how a forgotten password is recovered. Change it once and it applies everywhere, including to systems whose vendors would otherwise have taken a year to comply.
• Joiner, mover, leaver automation. Feed the service from the HR record and access follows employment automatically. The leaver problem, which is the single most common finding in any access audit, largely disappears.
• Context rules. Some access should depend on where and when. A billing counter account that only works from the hospital network during counter hours is a reasonable rule, and it is enforceable centrally rather than by policy memo.
• Break-glass with consequences. Emergency access is a real clinical requirement and should not be blocked. It should be logged loudly, flagged for review, and time limited. Centrally, that is a workflow. Per application, it is a promise.
• One audit thread. Because the same identity is used everywhere, a person's activity can be followed across systems. Today, tracing one user across a hospital's applications means correlating six log formats by hand and hoping the clocks agree.
• Machine identity. Interfaces, integrations and scheduled jobs also need credentials, and they are usually the worst managed of all: shared passwords in configuration files that no one dares rotate. Service accounts belong in the same registry, with the same lifecycle.
• Less personal data lying around. When applications stop keeping their own copies of names, phone numbers and staff records to support their own login screens, the number of places holding personal data falls. That is a real reduction in exposure, not a paper one.

Read that list again and notice what it is. It is most of an institution's operational control over its own information, and it is available because every system stopped answering "who is this?" for itself.

What it actually looks like

The technical shape is settled and does not need inventing. OpenID Connect handles authentication, layered on OAuth 2.0, which handles delegated authorization. Keycloak is the open-source identity server most commonly used to run it, and it speaks OpenID Connect and SAML, federates to an existing directory where one already exists, and issues tokens carrying the roles an application needs.

In practice, an institution gets its own realm. Applications are registered as clients within it. Staff sign in once and move between the hospital management system, the laboratory system and the reporting tool without signing in again, because each of those receives a token rather than a password. Older systems that cannot speak the protocol sit behind a small adapter, or are scheduled for replacement, and the adapter is what makes migration possible without a big-bang cutover.

There is no requirement to be online to a central server in another city for a clinician to log in at three in the morning. Identity can be deployed at the institution, with federation upward for the oversight functions. That distinction, local authentication with central governance, is what makes the model workable in Nepal rather than a diagram that assumes connectivity nobody has.

What to put in your next tender

The cheapest moment to fix this is before you buy the next system. Three lines in a specification will do more than a year of remediation afterwards:

• The application must authenticate users through OpenID Connect against the institution's identity provider, and must not maintain its own password store.
• The application must accept roles and group membership as token claims, and must not require local role assignment for those roles.
• The supplier must demonstrate this working against a test realm before acceptance, not describe it in a compliance statement.

Any serious product built in the last decade can meet those requirements. A supplier who cannot is telling you something useful about what you are being sold.

The honest caveats

Central authentication concentrates risk, and it is dishonest to present it otherwise. If the identity service is down, everything is down. It has to be run properly: more than one instance, tested restores, monitored certificates, and a documented procedure for the day it fails. An institution that cannot commit to operating one service well should not make ten systems depend on it.

Migration is also real work. Existing accounts must be matched to real people, and that exercise always uncovers accounts belonging to nobody, duplicates, and people who left years ago. That discovery is valuable, but it takes time and it is political, because someone has to decide what happens to the account that half the department has been sharing.

And identity does not fix a bad application. A system with weak internal authorization will still be weak; it will simply have a better front door. Central authentication tells you who is at the door and lets you decide what they may do. What the application does after that is still the application's problem.

Those are manageable costs, and they are one-time. The alternative cost is not one-time. It is paid every time someone joins, moves or leaves, every time a system is added, and every time somebody asks a question about access that the institution cannot answer.