/
Switching Context

Switching Context

Describes how client applications can switch context and request new tokens with updated context information from the Authentication Server (AS).

A key component of the eHealth Infrastructure security model is to switch context. Switching context means that the user asks the Authentication/Authorization Server (AS) to issue a new set of tokens where the content of the Access token contains a new context. The parameters for requesting a new context are any of the following:

  • Careteam

  • Patient

  • Episode of Care

  • Organization

To set a context, the requester needs to obtain what is available to be set in context.

Available Contexts

The available contexts for a given user can be obtained by querying the AS using an HTTP GET with the current Access token at the path /auth/realms/{realm name}/resource/ehealth-connect/contexts on the AS.

The result is an expanded tree that lists available careteams and organizations, e.g. for a clinical user:

Contexts
GET https://saml.exttest.ehealth.sundhed.dk/auth/realms/ehealth/resource/ehealth-connect/contexts Response: { "care_teams": [ { "id": "https://fut.com/fhir/CareTeam/4", "name": "Careteam Nord" "affiliation": { "id": "https://fut.com/fhir/Organization/38", "name": "Region Midtjylland, Aarhus Universitetshospital, Lungesygdomme" }, "roles": [ "urn:dk:sundhed:ehealth:role:clinical_viewer" ] }, { "id": "https://fut.com/fhir/CareTeam/6", "name": "Careteam Syd" "affiliation": { "id": "https://fut.com/fhir/Organization/1", "name": "Aarhus Kommune, Center Syd" }, "roles": [ "urn:dk:sundhed:ehealth:role:clinical_viewer", "urn:dk:sundhed:ehealth:role:citizen_enroller" ] } ], "organizations": [ { "id": "https://fut.com/fhir/Organization/1", "name": "Aarhus Kommune, Center Syd", "roles": [ "urn:dk:sundhed:ehealth:role:questionnaire_editor" ] }, { "id": "https://fut.com/fhir/Organization/2", "name": "Æbeltoft Kommune, Afdeling Vest", "roles": [ "urn:dk:sundhed:ehealth:role:terminology_administrator", "urn:dk:sundhed:ehealth:role:questionnaire_editor" ] } ] }

Mapping from Role to Privileges

As of Keycloak version 1.8.40, a list of the top-level roles for each available context is given in the “roles element“. Each top-level role is expanded to a set of privileges. This mapping can be obtained by querying (HTTP GET with the current Access token) the AS at the path /auth/realms/{realm name}/resource/ehealth-connect/groups. The result is a map of top-level roles to privileges. The example request and response shown below illustrate the concept and are not intended to be normative, complete or kept up-to-date.

Groups
GET https://saml.exttest.ehealth.sundhed.dk/auth/realms/ehealth/resource/ehealth-connect/groups { "urn:dk:sundhed:ehealth:role:questionnaire_editor": [ "Questionnaire.update", "DocumentReference.write", "DocumentReference.*", "Questionnaire.patch", "DocumentReference.read", "DocumentReference.update", "DocumentReference.search", "Organization.read", ... ], "urn:dk:sundhed:ehealth:role:clinical_viewer": [ "DeviceUseStatement.search", "Condition.search", "DeviceMetric.read", "DocumentReference.read", "DocumentReference.search", "RestrictionCategory$none", "$search-measurements", ... ], "urn:dk:sundhed:ehealth:role:terminology_administrator": [ "CodeSystem.write", "Terminology Administrator", "ConceptMap.write", "ValueSet.write", "NamingSystem.write" ], "urn:dk:sundhed:ehealth:role:citizen_enroller": [ "Condition.search", "CarePlan$update-care-teams", "DocumentReference.read", "Consent.create", "DocumentReference.search", "CareTeam.read", "Consent.update", "ServiceRequest.delete", "Consent.patch", "EpisodeOfCare.write", "Questionnaire.search", ... ], ... }

Setting the Context

To set the context, the AS can be requested with a valid refresh token using an HTTP POST (x-www-form-urlencoded) against auth/realms/{realm name}/protocol/openid-connect/token with the required and optional parameters listed below. The result is a valid Access Token Response[1] where the access token in the response will have the requested context set.

[1] https://www.oauth.com/oauth2-servers/access-tokens/access-token-response/

Example request:

Example context
POST /auth/realms/ehealth/protocol/openid-connect/token Accept-Encoding: text Content-Type: application/x-www-form-urlencoded Accept: */* Cache-Control: no-cache Host: login.fut.trifork.com Content-Length: 941 Connection: keep-alive grant_type=refresh_token& client_id=keyservice_client& refresh_token=eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICIyNWIwYzE0ZS05ZTRhLTQ2NTAtODAzMS0xMjM4YjBhNGRjMjMifQ.eyJqdGkiOiJiOWRmMDAyYi1jN2VlLTRmZmEtYWU1MS00OGVlMGZjMDMyNWUiLCJleHAiOjE1NjYzODUwNDMsIm5iZiI6MCwiaWF0IjoxNTY2MzgzMjQzLCJpc3MiOiJodHRwczovL2xvZ2luLmZ1dC50cmlmb3JrLmNvbS9hdXRoL3JlYWxtcy9laGVhbHRoIiwiYXVkIjoiaHR0cHM6Ly9sb2dpbi5mdXQudHJpZm9yay5jb20vYXV0aC9yZWFsbXMvZWhlYWx0aCIsInN1YiI6ImFmYWZlYTJhLTY1ZWQtNDJhNy04YjMzLWMxNTdkYTIyYTA5NyIsInR5cCI6IlJlZnJlc2giLCJhenAiOiJrZXlzZXJ2aWNlX2NsaWVudCIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6IjFlYjIxNjhjLTVlN2EtNGRiMi04ZTVlLWI3NzVjNGRkNWMxOSIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJvZmZsaW5lX2FjY2VzcyIsInVtYV9hdXRob3JpemF0aW9uIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJwcm9maWxlIGVtYWlsIn0.Yv22YYcyQYYnj_OJMJ3kwsgq9gpAnHhtTFUfcbXLRcs& organization_id=https%3A%2F%2Ffut.com%2Ffhir%2FOrganization%2F38& care_team_id=https%3A%2F%2Ffut.com%2Ffhir%2FCareTeam%2F4& episode_of_care_id=https%3A%2F%2Ffut.com%2Ffhir%2FEpisodeOfCare%2F10& patient_id=https%3A%2F%2Ffut.com%2Ffhir%2FPatient%2F8

Note: The original JWT used to obtain a new JWT with the context set is still valid for other operations.



Parameter name

Description

Parameter name

Description

client_id

Required. The OAuth2 client id

grant_type

Required. Fixed to the value of the ‘refresh_token’

refresh_token

Required. The refresh token of the current session

care_team_id (context)

Optional. A valid absolute FHIR URI pointing to a Careteam resource. This adds implicit organization context given the organization constraint in the OIO BPP structure

organization_id (context)

Optional. A valid absolute FHIR URI pointing to an Organization resource

episode_of_care_id (context)

Optional. This adds implicit patient context. A valid absolute FHIR URI pointing to an Episode of Care resource

patient_id (context)

Optional. A valid absolute FHIR URI pointing to a Patient resource



Example: Access token with context

Context example



Sequence Flow

The diagram below illustrates the interacting parts when logging in and requesting a context:

Related content

Access Control in eHealth Services
Access Control in eHealth Services
More like this
Security Mechanisms
Security Mechanisms
More like this
Client Application use of eHealth Infrastructure authentification server (AS)
Client Application use of eHealth Infrastructure authentification server (AS)
Read with this
Token Based Security
Token Based Security
More like this
Error Codes when a client requests tokens
Error Codes when a client requests tokens
Read with this
Behind the Scenes
More like this