| Excerpt |
|---|
The eHealth Infrastructure has two Authorization |
...
Services (AS) configurations providing authentication and authorization for client systems and internal use. |
Content
| Table of Contents |
|---|
Subpages
| Child pages (Children Display) | ||||
|---|---|---|---|---|
|
Authorization Service Configurations
The Authorization Service configurations support the following user types of the eHealth Infrastructure:
citizen
clinical and /or administrative employee
service, support & logistics (SSL) supplier employee
system users
system administrator users
The AS configurations consists consist of:
One KeyCloak with
realm ehealth - for clinical and /or administrative employee login
realm nemlogin - for citizen login
One SSL KeyCloak with
realm ssl SSL - SSL supplier employee login
System users and system administrator users exist in all the realms.
Authentication and Authorization Flow
...
Further details on the client’s initiation are described in Client UseApplication use of eHealth Infrastructure authentification server (AS). As a reaction, the Authorization Service initiates a federation of authentication and possibly authorization depending on the realm:
realm nemlogin is federated to Nemlogin
realm ehealth eHealth is federated to SEB (in Danish: Sundhedsvæsenets Elektroniske Brugerstyring shortened SEB) which is a common platform for user administration of the solutions provided by the National Health Data Authority
realm ssl SSL is/can be federated to SSL suppliers' IdPs
| Info |
|---|
In non-production environments, login without this federation actually taking place can be simulated through use of the so-called mocked users. Mocked users are authenticated (and authorized depending on variant) in the eHealth Authentication Services. |
After successful authentication, three tokens are issued for separate purposes:
an ID token – information for the client system about the authenticated user.
an Access Token (AT) – a token with a relatively short period of validity (a few minutes), which the client systems must include in all service requests.
a Refresh Token (RT) – a token with a long validity, which can be used to renew the AT, thereby extending or resuming the session without the user having to authenticate again.
...
Organization Context
Careteam Context
Patient Context
Episode of Care Context
| Info |
|---|
The following is an informative overview of user types must present what contexts. The normative mapping is described in Access Control in eHealth Services. |
Citizen User Type and Contexts
A citizen user type is authorized to see almost all data pertaining to about the citizen.
This user type will have the Patient Context set.
In general, modifying data requires the Episode of Care Context being to be set.
| Info |
|---|
Citizens that logs into the infrastructure using NemID are looked up as FHIR Patient resources with the social security number found in the SAML assertion. If a match is found, the FHIR Patient resource ID will be present in the Refresh Token handed back to the client. If no match to a FHIR Patient resource is found, no FHIR Patient resource ID will be present in the Refresh Token. This means that citizens that are not part of any treatment in the infrastructure will be allowed to login, but won't have any rights to read or write any data. |
Clinical and/or Administrative Employee User Type and Contexts
| Info |
|---|
Whenever clinicians passes a successful loginflow the data from the SAML assertion is parsed and converted to the matching FHIR resources Practitioner, PractitionerRole and CareTeam which are updated in the infrastructure. This means that clinicians (FHIR Practitioners) will be present after login. This also means that clinicians that haven't logged in, won't be present as FHIR resources. Besides the creation and update of the FHIR resources, the loginflow also results in short lived session within the AS (Keycloak). The lifetime of the Keycloak session follows the lifetime of the Refresh Token. |