Concept explainer
Single sign-on
Explains how staff sign in through the hospital's own identity provider over SAML 2.0 or OpenID Connect, while access stays decided inside Pensieve.
Pensieve signs staff in through the hospital's own identity provider, so each person uses the account the hospital already manages for them. This page explains the protocols Pensieve accepts, how a sign-in runs, and which decisions stay with the identity provider and which stay with Pensieve.
SAML 2.0 and OpenID Connect
An identity provider is the service that holds the hospital's staff accounts and confirms who is signing in. Single sign-on is configured for each organisation from details the hospital supplies about its identity provider, and an organisation can hold more than one configuration.
Each configuration speaks one of two protocols. In both, the sign-in starts at Pensieve, and the table sets out what returns to Pensieve and what it checks before it trusts the answer.
| Aspect | SAML 2.0 | OpenID Connect |
|---|---|---|
| Flow | Web browser single sign-on, started by Pensieve as the service provider | The authorisation code flow with PKCE, started by Pensieve |
| What returns to Pensieve | A signed assertion, posted back through the person's browser | A one-time code, which Pensieve redeems at the provider's token endpoint for an ID token |
| What Pensieve checks | A single assertion whose own signature verifies against a certificate held in that identity provider's configuration; its issuer, audience, validity window and recipient; that it answers a request Pensieve made; and that it is used once | The state and nonce Pensieve issued, each used once; the ID token's issuer, audience and validity window; and its signature against the provider's published keys, with asymmetric algorithms only |
| What names the person | The assertion's name identifier | The ID token's subject |
| What the configuration holds | The provider's identifier, its sign-in address and its public signing certificates, more than one while a certificate rolls over | The issuer, the client identifier, the provider's endpoints and key set address, and a reference to the client secret in the platform's secret store |
How a sign-in runs
Pensieve opens each sign-in with a single-use request and sends the browser to the identity provider. The provider signs the person in under its own policy, any second factor included, and the browser carries the answer back to Pensieve.
Pensieve checks that answer as the table above sets out, finds or creates the person, and confirms their account is active. Only then does it open a session of its own. A failed check of any kind ends in one generic refusal, and the attempt is recorded as a failed sign-in.
The first sign-in
Pensieve provisions staff just in time: a person's first sign-in creates their identity inside the organisation that owns the configuration. That organisation is taken from the configuration alone, so an assertion cannot place a person in another organisation, whatever it claims.
The new identity carries no role. An administrator grants the person a role at each site where they work, in Nexus Manager, and their access starts from that grant. An administrator can also bring staff in before their first sign-in, one at a time by invitation or many at once by bulk import, as inviting staff and bulk loads describe.
What each side decides
The identity provider's answer settles who the person is. Each action they take after that is decided inside Pensieve, from the role they hold at the site and their care relationship to the patient, as how a permission is decided sets out.
Roles and relationships are held in Nexus Manager and Cirith Manager alone, and a person's groups and attributes at the identity provider carry no access into Pensieve. A change of job is made in Pensieve, where the next decision reads it.
The session after sign-in
The person then works in a Pensieve session, with the length, idle lock and points of re-authentication set out in sessions and timeouts. How a shared ward machine passes from one person's session to the next is described in shared workstations.
Disabling a person in Nexus Manager ends every session they hold and refuses their next sign-in, whatever the identity provider answers. It also suspends their rostered duties and raises each gap for reassignment.
A leaver is disabled in Pensieve as well
At the identity provider, disabling a person stops only the sign-ins that pass through it. A PIN they set on a shared workstation still signs them in, and the sessions they already hold continue. A leaver is therefore disabled in Nexus Manager at the same time, which refuses every sign-in.
Common confusions
Do staff need a Pensieve account before their first sign-in?
The first sign-in creates the identity. The person reaches the work of a site once an administrator grants them a role there in Nexus Manager.
Can one organisation use more than one identity provider?
An organisation can hold more than one configuration, and each configuration signs its people into that same organisation.
Where does a second factor apply?
At the identity provider, under its own policy, before its answer returns to Pensieve. The re-authentication points inside a Pensieve session are listed in sessions and timeouts.
Read how each machine and service proves itself in authentication between systems, and how one identity follows a person across sites in identity and sign-in.