This is a description of the token-based security the eHealth infrastructure use to authenticate the identity of users and control access to resources.

Token Based Security

Once the user is logged in, the eHealth Authentification Server (AS) hands out a set of tokens. These tokens serve as 'tickets' and are verified and asserted every time the user interacts with the eHealth Infrastructure.

The tokens are based on the OIO SAML AuthResponse. See Authentication and Authorization for details on the tokens.

If the eHealth Infrastructure deems the tokens invalid or expired, no further interaction happens and the user is denied from accessing or manipulating data. As the tokens from the login initially are a very broad spectrum, little or no data is accessible. This entirely depends on the information given in the OIO SAML AuthResponse. If the user e.g. happens to be part of multiple careteams, the AS is unable to supply proper default values as the choice is not unambiguously. This is because the access to data under each careteam may differ from careteam to careteam. To gain access to eg. clinical or organizational data, the user needs to actively choose in which context the user wants to interact. Based on the choice of context, the eHealth Infrastructure can forge a new set of tokens (based on the initial handed-out tokens + the chosen context - see Switching Context for details) which then provides access under the given chosen context.

Possible contexts are

Episode of care
Patient
Organization
Careteam

Each time one or more of these context items are provided in the step where the user chooses a given context, a consistency check is made in the eHealth Infrastructure order to check that the chosen set of context items fits together. All in all, without going into details it can be stated that the security model does both RBAC and ABAC security checks.

Besides granting access to organizational data, the Organization-context is also used for audit logging and the national NSP service, MinLog2.

The Access Token

When a user is logged into the eHealth Infrastructure a set of tokens are issued to the user. This section explains the Access token in further detail.

The Access token is a JWT with a set of fields that explain what a user is allowed to do in combination with the applied context. The fields of the JWT are the following:

JWT	Meaning	Example
preferred_username	value of SAML attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	C=DK,O=TRIFORK A/S // CVR:20921897,CN=Lasse Læge-Dam,Serial=CVR:20921897-RID:93134986
name	value of SAML attribute urn:oid:2.5.4.3	Lasse Læge-Dam
jti	See https://www.iana.org/assignments/jwt/jwt.xhtml	2ef5b6b1-a667-40f5-b468-f475cdcef5ec
exp	See https://www.iana.org/assignments/jwt/jwt.xhtml	1556110351
nbf	See https://www.iana.org/assignments/jwt/jwt.xhtml	0
iat	See https://www.iana.org/assignments/jwt/jwt.xhtml	1556110051
iss	See https://www.iana.org/assignments/jwt/jwt.xhtml	https://inttest.ehealth.sundhed.dk/auth/realms/inttest
aud	See https://www.iana.org/assignments/jwt/jwt.xhtml	EHealth
sub	See https://www.iana.org/assignments/jwt/jwt.xhtml	88c4feb3-f87a-43c6-9141-fc03a3944ad6
typ	See https://tools.ietf.org/html/rfc7519	Bearer
azp	See https://www.iana.org/assignments/jwt/jwt.xhtml	EmployeeClient
acr	See https://www.iana.org/assignments/jwt/jwt.xhtml	1
auth_time	See https://www.iana.org/assignments/jwt/jwt.xhtml	0
scope	Scope is either ehealth or nemlogin	profile openid ehealth
realm_access	List of process privileges – eg. what is the user allowed to do in combination with the context.	"realm_access": { "roles": [ "Patient.read", "Patient.write" ] }
context	List of items that are set in context. context in combination with items in realm_access governs the access to all resources in the ehealth infrastructure.	"context": { "organization_id" : "https://fut.com/fhir/Organization/1", "care_team_id": https://fut.com/fhir/CareTeam/4, "episode_of_care_id": https://fut.com/fhir/EpisodeOfCare/10, "patient_id": "https://fut.com/fhir/Patient/8" }
user_id	Id of the user. Can be either a FHIR patient Id, FHIR practitioner Id or a KeyCloak Id	"user_id": " e03ccef7-b0b1-4f68-8e16-6fc2f865a922"
user_type	Can be either SYSTEM, PATIENT, PRACTITIONER or SSL	"user_type": "PATIENT"

What operations that the user is allowed to do is stated in the "realm_access" attribute. In the example above the user is allowed to issue a "Patient.read" and a "Patient.write". This means that the user can get and edit patient records. This part of the security model is the RBAC part, as the claims here are entirely based on what role the user has. Each resource type (see https://docs.ehealth.sundhed.dk/latest/ig/profiles.html) has certain restrictions to what context must be issued, to allow data retrieval or data manipulation. This is stated in the Access rights section below (For instance, to either read/search or write to a patient, the patient must be in context). Furthermore, the context attribute shows what data is in context. The set of items that can be set into context are Organization, Patient, CareTeam, and EpisodeOfCare (see Switching Context). As such, the eHealth Infrastructure governs the access to data using both RBAC (stated roles from login) and ABAC (asserting data attributes on the actual content).

Privilege Roles

Privilege roles are the roles that are part of the issued OIO BPP. These roles SHALL match the roles stated in the AS. The AS is the master data repository of the privileged roles. Roles issued in the OIO BPP that do not match the roles defined in AS are ignored.

The current list of privilege roles defined is given in the table below.

OIO BPP Role Role to Privilege mapping lists all the privileges for each role.

	Role name in OIO BPP	Domain	Danish name	Description (non-normative)	Privileges (Danish)	OIO Data constraints (Exttest)
1	`urn:dk:sundhed:eehealth:role:careteam_administrator`	Administrative	Care Team administrator	Role capable of creating and maintaining careteams	Se Care Team Opret Care Team Ændre Care Team Slet Care Team	STS Organisationsenhed (Obligatorisk)
2	`urn:dk:sundhed:ehealth:role:citizen_enroller`	Clinical	Borgeropretter	Role capable of initiating episode of care and setting up careplans for Citizen	Opret borger Tildel borger telemedicinsk forløb og pakke Opret Måleregime for borger Tildele standard Grænseværdier til borger	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
3	`urn:dk:sundhed:ehealth:role:clinical_administrator`	Administrative	Pakke- og forløbsbygger	Role capable of creating and maintaining plan definitions	Se telemedicinsk pakke/forløb Opret telemedicinsk pakke/forløb Ændre telemedicinsk pakke/forløb Slet telemedicinsk pakke/forløb Se Måleregime for telemedicinsk pakke/forløb Opret Måleregime for telemedicinsk pakke/forløb Ændre Måleregime for telemedicinsk pakke/forløb Slet Måleregime for telemedicinsk pakke/forløb	STS Organisationsenhed (Obligatorisk)
4	`urn:dk:sundhed:ehealth:role:clinical_supporter`	Support, Service & Logistics	Klinisk supporter	Role capable of searching and updating communications related to support and incidents	Se i hændelseslog Søge i hændelseslog	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
5	`urn:dk:sundhed:ehealth:role:clinical_viewer`	Clinical	Klinisk se adgang	Role capable of viewing a citizen's demographic data, careplans and measurements.	Fremsøge borger Se borgers Stamdata Se Måledata fra borger Se pausering for borger Se og søge handlevejledninger og fortolkede visninger	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
6	`urn:dk:sundhed:ehealth:role:incident_manager`	Support, Service & Logistics	Support samarbejdspartner	Role capable of dispatching incidents and tracking status.	Modtager og behandler fejlmelding Håndterer track og trace på fejlsag/status/håndtering	STS Organisationsenhed (Obligatorisk) Careteam (Obligatorisk)
7	`urn:dk:sundhed:ehealth:role:incident_reporter`	Support, Service & Logistics	Fejlmelder	Role capable of creating and maintaining communications related to support and incidents.	Sender fejlmelding Ændrer fejlmelding Sletter/annulerer fejlmelding	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
8	`urn:dk:sundhed:ehealth:role:monitoring_adjuster`	Clinical	Monitoreringstilretter	Role capable of maintaining careplans, setting up measurement regimes and reference ranges, suspending and reactivating careplans, handling communication with Citizen.	Ændre i oprettelse af borger Slette/fjerne oprettelse af borger Tilføje yderligere til borgers stamdata Ændre i borgers stamdata Slette i borgers stamdata Ændre i telemedicinsk forløb/pakker hos borger Slette telemedicinsk forløb/pakker hos borger Ændre i Måleregime for borger Slette Måleregime for borger Slette/fjerne Måledata fra borger Ændre Grænseværdier for borger Slette Grænseværdier for borger Ændre i pausering for borger Slette pausering for borger Håndtere/kvittere for/sortere kommunikation med borger Ændre videoaftale med borger Slette videoaftale med borger	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
9	`urn:dk:sundhed:ehealth:role:monitoring_assistor`	Clinical	Monitoreringsmedhjælper	Role capable of handling measurements and communication with Citizen.	Fremsøge grupper af borgere Se telemedicinsk forløb og pakker hos borger Se Måleregime hos borger Vurdere/håndtere/kvittere for Måledata fra borger Se Grænseværdier til borger Oprette pausering for borger Se kommunikation til/fra borger Skrive kommunikation til borger Se videoaftaler med borger Oprette videoaftale Afvikle videoaftale	Careteam (Obligatorisk) STS Organisationsenhed (Obligatorisk)
10	`urn:dk:sundhed:ehealth:role:order_placer`	Support, Service & Logistics (secondary: Clinical)	Bestiller af udstyr	Role capable of accessing carePlans, placing orders for devices and services, maintaining orders	Se udstyr koblet på telemedicinsk forøb/pakke Bestil udstyr til telemedicinsk forøb/pakke Ændre bestilling Slette bestilling Bestil nedtagning af udstyr/pakke Se track og trace på bestilling	STS Organisationsenhed (Obligatorisk)
11	`urn:dk:sundhed:ehealth:role:questionnaire_editor`	Administrative	Sundhedsfaglig spørgeskemaeditor	Role capable of creating and maintaining questionnaires	Oprette, ændre, se og søge Spørgeskema Oprette, ændre, se og søge handlevejledninger og fortolkede visninger	STS Organisationsenhed (Obligatorisk)
12	`urn:dk:sundhed:ehealth:role:report_user`	Administrative	Nøgletalsmedarbejder	Role capable of generating reports for statistics and administration	Fremsøge alle borgere Se statistisk data Udtrække statistisk data Generere statistisk rapport	STS Organisationsenhed (Obligatorisk)
13	`urn:dk:sundhed:ehealth:role:service_and_logistics`	Support, Service & Logistics	Service og logistik samarbejdspartner	Role capable of processing orders for devices and services	Modtager og behandler bestilling Håndterer track og trace på bestilling	STS Organisationsenhed (Obligatorisk) Careteam (Obligatorisk)
14	`urn:dk:sundhed:ehealth:role:ssl_catalogue_annotator`	Support, Service & Logistics	Katalogopmærker	Role capable of accessing SSL catalogues and maintaining annotations about devices	Se kataloger Se, opret og ændre annoteringer til udstyr i kataloger	STS Organisationsenhed (Obligatorisk)
15	`urn:dk:sundhed:ehealth:role:ssl_catalogue_responsible`	Support, Service & Logistics	Katalogansvarlig	Role capable of creating and maintaining SSL catalogues	Se, opret og ændre (herunder nedlæg) kataloger over udstyr og ydelser	STS Organisationsenhed (Obligatorisk)
16	`urn:dk:sundhed:ehealth:role:ssl_contract_responsible`	Support, Service & Logistics	Aftaleansvarlig	Role capable of creating and maintaining SSL contracts and involved parties	Se kataloger Se, opret og ændre kontrakter på mulighed for bestilling af udstyr og ydelser.	STS Organisationsenhed (Obligatorisk)
17	`urn:dk:sundhed:ehealth:role:terminology_administrator`	Administrative	Terminologiadministrator	Role capable of creating and maintaining terminology	Se, opret og ændre klassifikationer og udfaldsrum Se naming systems, se terminologi-mapninger	STS Organisationsenhed (Obligatorisk)

Mapping Privilege Roles to Roles

Each privilege role maps to a set of roles stated in the JWT attribute "realm_access". The table below illustrates this by example. These roles are the RBAC part of the security model.

Role name in OIO BPP	Unfolded to `realm_access.roles`
`urn:dk:sundhed:ehealth:role:monitoring_assistor`	Patient.read, Observation.read, CareTeam.read, Organization.read, …
`urn:dk:sundhed:ehealth:role:clinical_administrator`	PlanDefinition.read, PlanDefinition.write, ActivityDefinition.read, ActivityDefinition.write, …

The current mapping in effect can be retrieved from KeyCloak as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/270991361/Switching+Context#Mapping-from-Role-to-Privileges.

Access Control

See Access Control in eHealth Services for details on the access control in eHealth Services.