| Excerpt |
|---|
Description of how client applications can switch context and Authentication/Authorization Server (AS) to issue a new set of tokens where the content of the Access token contains a new context. |
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:
...
The available contexts for a given user can be obtained by querying the AS using a 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
| Code Block | ||
|---|---|---|
| ||
GET https://saml.exttest.ehealth.sundhed.dk/auth/realms/ehealth/resource/ehealth-connect/contexts |
...
Response
| Code Block | ||
|---|---|---|
| ||
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"
]
}
]
}
|
...
As of Keycloak version 1.8.40, a list of the top-level roles for each available context are is given in the “roles element“. Each top-level role are is expanded to a set of privileges. This mapping can be 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. e. g.:The example request and response shown below illustrate the concept and are not intended to be normative, complete or kept up-to-date.
Groups
| Code Block | ||
|---|---|---|
| ||
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",
...
],
...
} |
...
Note: The original JWT used to obtain a new JWT with the context set is still valid for other operations.
Parameter name | Description |
|---|---|
client_id | Required. The OAuth2 client id |
grant_type | Required. Fixed to the value of the of ‘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
...