Versions Compared

Old Version 90

changes.mady.by.user John Schneider

Saved on

compared with

New Version Current

changes.mady.by.user malthe lange

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt

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

Table of Contents

Token Based Security

Once the user is logged in, the eHealth Authentification Server (AS) hands out a set of tokens (see Authentication and authorization for details on the tokens) are handed out by the AS (based on the OIO SAML AuthResponse). These tokens servers serve as 'tickets' and are verified and asserted every time the user interacts with the eHealth Infrastructure. If deemed  

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 by the eHealth Infrastructure, 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 spectredspectrum, 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 due to because the fact that the access to data under each careteam may differ from careteam to  to careteam. In order to actually 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. 

...

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 actually fit 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, MinLogMinLog2.

The Access Token

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

The Access token is a JWT with at a set of fields that explains 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

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 upon on what role the user has. Each resource type (see https://docs.ehealth.sundhed.dk/latestfhir/ig/profiles.html) has certain restrictions to what context must be issued, in order to allow data retrieval or data manipulation. This is stated in the Access rights section below (For instance, in order 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 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 privileges privileged roles. Roles issued in the OIO BPP that does do not match the roles defined in AS are ignored.

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

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

Role name in OIO BPP

Domain

Danish name

Description (non-normative)

Privileges

(danish)

(Danish)

OIO Data constraints (Exttest)

OIO Data constraints (Prod)

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:

monitoring_assistor

incident_manager

Support, Service & Logistics

Support samarbejdspartner

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

    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

    urn:dk:sundhed:ehealth:role:questionnaire_editor

    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

    • Careteam (Obligatorisk)

    • STS Organisationsenhed (Obligatorisk)

    9

    urn:dk:sundhed:ehealth:role:

    clinical_administrator

    monitoring_assistor

    Clinical

    Monitoreringsmedhjælper

    Role capable of

    creating and maintaining plan definitions

    handling measurements and communication with Citizen.

    • Fremsøge grupper af borgere

    • 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

    • urn:dk:sundhed:ehealth:role:clinical_supporter

    Role capable of searching and updating communications related to support and incidents

  • Se i hændelseslog

    • Søge i hændelseslog

    • 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:

    incident_reporter

    order_placer

    Support, Service & Logistics

    (secondary: Clinical)

    Bestiller af udstyr

    Role capable of

    creating and maintaining communications related to support and incidents.

  • Sender fejlmelding

  • Ændrer fejlmelding

    • Sletter/annulerer fejlmelding

    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:

    incident_manager

    questionnaire_editor

    Administrative

    Sundhedsfaglig spørgeskemaeditor

    Role capable of

    dispatching incidents and tracking status.

  • Modtager og behandler fejlmelding

    • Håndterer track og trace på fejlsag/status/håndtering

    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:

    careteam_administrator

    Role capable of creating and maintaining careteams

    • Se Care Team

    • Opret Care Team

    • Ændre Care Team

    • Slet Care Team

    urn:dk:sundhed:ehealth:role:order_placer

    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

    urn:dk:sundhed:ehealth:role:service_and_logistics

    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:

    terminology_administrator

    ssl_catalogue_annotator

    Support, Service & Logistics

    Katalogopmærker

    Role capable of

    creating

    accessing SSL catalogues and maintaining

    terminology

    annotations about devices

    • Se kataloger

    • Se, opret og ændre

    klassifikationer og udfaldsrumSe naming systems, se terminologi-mapninger

    • 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_

    catalogue_annotator

    contract_responsible

    Support, Service & Logistics

    Aftaleansvarlig

    Role capable of

    accessing

    creating and maintaining SSL

    catalogues and maintaining annotations about devices

    contracts and involved parties

    • Se kataloger

    • Se, opret og ændre

    annoteringer til udstyr i kataloger

    • kontrakter på mulighed for bestilling af udstyr og ydelser.

    • STS Organisationsenhed (Obligatorisk)

    17

    urn:dk:sundhed:ehealth:role:

    ssl_contract_responsible

    terminology_administrator

    Administrative

    Terminologiadministrator

    Role capable of creating and maintaining

    SSL contracts and involved parties

    terminology

    • Se

    katalogerSe

    • , opret og ændre

    kontrakter på mulighed for bestilling af udstyr og ydelser.

    • 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

    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.