The infrastructure eHealth Infrastructure provides a login component, which is the client systems' access to user authentication and authorization. This functionality is implemented in the Authorization ServerService. The login protocol between the client systems and the login component will follow is the standard OpenID Connect. Authentication should be done by completing an OpenID Connect "code flow".
...
Authentication Code Flow of OpenID Connect 1.0.
...
The eHealth Infrastructure performs federated authentication (and sometimes authorization) using Security Assertion Markup Language (SAML) based, external infrastructure. This is described in Federated Authentication and Authorization and subpages.
After successful authentication, three tokens are issued for separate purposes:
...
The details on how to use these tokens will vary, depending on whether the client system is for citizens or employees, as well as specific security requirements for the called service. There will be services that do not return personal data and therefore require less protection, while other services will require both authentication, context information and more detailed authorization. The login flow is described on the Login page. The data that lays the basis for authorization and authentication is found in the final SAML Assertion that is passed to the AS.
Authentication for citizen clients
Client systems for citizens will in their (initial) login be met by NemID, which is presented via a federated login service from NemLogin. If the client system is running on a platform that supports it, it will be possible to store the RT and apply this later to resume an authenticated session, based on either pin code or biometric data. Details of this is can be read on Key Service overview, but in essence it involves selecting a PIN, registering a user / device / PIN via the Key Service, and resuming the session based on stored data and calling the Key Service.
The aim of this is to make an alternative - but simpler - "authentication" available to citizens in a secure manner.
Authentication for clinical clients
Client systems for clinical users will make a login which delegates to SEB. If there is already a session in SEB from the same browser, then a single-signon experience can be realized. Through SEB, a number of information about the user is handed over to AS, including clinical user's roles / rights. These roles and rights are embedded in the SAML Assertion using the OIO BPP 1.1 structure, model 3, described in the following section.
Authorization, SAML requirements and OIO BPP
Accessing data (one's authorization) in the eHealth Infrastructure is split into to sections; one for citizens and one for non-citizens:
...
The rules that apply are determined by the SAML Assertion when logging in. The SAML attributes are described below.
Citizen SAML attributes
Citizen access to the eHealth Infrastructure goes through NemLogin. NemLogin provides a set of SAML attributes in a SAML assertion which is used to identify the citizen. Other attributes are also part of the SAML attribute; they are however not currently used. The table below lists the current attributes that are delivered by NemLogin:
...
Citizens accessing the eHealth Infrastructure is handled a bit differently from other users accessing the platform. As citizens do not carry a context of roles and rules, it is limited to the citizen itself and scoped by the provided SAML attributes. This means that the citizen is not able to switch context and that the citizen can only access data being scoped to him/herself. The scope of access is determined by setting the citizen in context of him/herself and not allowing context switches.
Clinical SAML attributes
Clinical access to the eHealth Infrastructure goes through SEB. SEB provides a set of SAML attributes in a SAML assertion which is used to identify the clinical user.
...
The attributes used are the CPR number (dk:gov:saml:attribute:CprNumberIdentifier), the UID and the OIO BPP format (dk:gov:saml:attribute:Privileges_intermediate). The CPR number is primarily used for delivering data to the centra NSP MinLog service. The UID uniquely identifies the user in the eHealth Infrastructure and the OIO BPP provides the roles and careteams that are accessible to the user.
OIO BPP in the eHealth Infrastructure
| Note |
|---|
Municipalities MUST follow the guidelines located here: OIO-BPP URI naming precautions for municipalities |
The structure of the OIO BPP, used in Privileges_intermediate, is capable of expressing multiple careteam- and organization affiliations. If only a single careteam is expressed in the OIO BPP it is automatically set in context of the user. In the case where the user is part of multiple careteams, the user needs to set the wanted careteam in context (see Switching Context). Once a careteam is set into context, the roles under that careteam applies to the user - expressed in the JWT (the internal access token of the eHealth Infrastructure).
An example:
OIO BPP
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="UTF-8"?>
<bpp:PrivilegeList
xmlns:bpp="http://itst.dk/oiosaml/basic_privilege_profile"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:29190925">
<Constraint Name="urn:dk:gov:saml:sorIdentifier">440711000016004</Constraint>
<Constraint Name="urn:dk:sundhed:ehealth:careteam">95c7aef7-ec7f-487b-9687-6e6624d25fdb</Constraint>
<Privilege>urn:dk:sundhed:ehealth:role:monitoring_assistor</Privilege>
</PrivilegeGroup>
</bpp:PrivilegeList> |
...
Since the OIO BPP states what privileges are available to the user, it is up to the IdP to construct the correct OIO BPPs. Valid privileges and what they map to can be seen at Tokens, Roles and RBAC/ABAC.
Enhanced example:
Enhanced OIO BPP
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="UTF-8"?>
<bpp:PrivilegeList
xmlns:bpp="http://itst.dk/oiosaml/basic_privilege_profile"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:29190925">
<Constraint Name="urn:dk:gov:saml:sorIdentifier">440711000016004</Constraint>
<Constraint Name="urn:dk:sundhed:ehealth:careteam">95c7aef7-ec7f-487b-9687-6e6624d25fdb</Constraint>
<Privilege>urn:dk:sundhed:ehealth:role:monitoring_assistor</Privilege>
<Privilege>urn:dk:sundhed:ehealth:role:citizen_enroller</Privilege>
</PrivilegeGroup>
<PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:29190925">
<Constraint Name="urn:dk:kombit:orgUnit">48df8b3d-56be-4f3a-bd0f-d3ade05348dd</Constraint>
<Privilege>urn:dk:sundhed:ehealth:role:clinical_administrator</Privilege>
<Privilege>urn:dk:sundhed:ehealth:role:questionnaire_editor</Privilege>
</PrivilegeGroup>
</bpp:PrivilegeList> |
...
The combination of CVR number (scope) sorIdentifer(regional)/orgUnit(municipal) (and careteam must be unique). Failing to comply with this may result in errors. This scheme is to ensure that users cannot have multiple different privileges stated differently. Do note that it is possible to list multiple (valid) privileges in any given PrivilegeGroup.
Result and impact of successful login
Clinicians
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.
Citizens
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.