...

Content

Subpages

Authorization Service Configurations

The Authorization Service configurations support the following user types of the eHealth Infrastructure:

• citizen

• clinical and administrative employee

• service, support & logistics (SSL) supplier employee

• system users

• system administrator users

The AS configurations consist of:

• One KeyCloak with

  • realm ehealth - for clinical and administrative employee login

  • realm nemlogin - for citizen login

• One SSL KeyCloak with

  • realm SSL - SSL supplier employee login

System users and system administrator users exist in all realms.

Authentication and Authorization Flow

The login protocol between the client systems and the login component will follow the standard is the OpenID Authentication Code Flow of OpenID Connect 1.0. Authentication should be done by completing an OpenID Connect "code flow"

...

Further details on the client’s initiation are described in Client Application 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 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 is/can be federated to SSL suppliers' IdPs

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.

NOTE: AT and RT are tokens that may be in JWT format, but the user systems must not assume this. The format of these may change without notice, and may for example be so-called "opaque tokens", which basically are just an ID string that does not in itself carry any information.

The AT is sent as an HTTP header in all service requests in this form (where "<access token>" is replaced by a specific AT) - see https://jwt.io/introduction/ for further introduction:

Authorization: Bearer <access token>

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:

• Citizens are able to see almost all data to whom they are referenced (see Tokens, Roles and RBAC/ABAC). Citizens are able to create and manipulate data in the eHealth Infrastructure according to the same set of RBAC and ABAC rules.
• Clinical users are able to access and manipulate data according to their affiliation to a given careteam and the role in that given careteam. The same goes for organizational data (see Tokens, Roles and RBAC/ABAC).

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.

...

[1] https://digst.dk/media/19020/oiosaml-basic-privilege-profile-1_1.pdf

...

Optional. Can be used to limit scopes expressed in the OIO BPP structure, by adding it as a constraint in each PrivilegeGroup. Only PriviledgeGroups with the constraint matching the value of scopingOIOBPPContext will be available for the user. The use of scopingOIOBPPContext is not yet used and will be ignored. Can be used to support multi affiliation in the future.

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

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:

<?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_responsible</Privilege>
    </PrivilegeGroup>
</bpp:PrivilegeList>

The OIO BPP snippet above is listed for Practitioner 1 - Lasse Dam. This OIO BPP states that Lasse Dam has the role "urn:dk:sundhed:ehealth:role:monitoring_responsible" in the careteam identified by "95c7aef7-ec7f-487b-9687-6e6624d25fdb" in the organization "440711000016004". If this was the only content of the OIO BPP, Lasse Dam would have been handed a JWT by the infrastructure where the stated careteam and organization would be set in context. Had there been multiple PrivilegeGroups in the OIO BPP, nothing would have been set in context as the choice would not be straight forward for the AS to pick, instead the client would have to ask the user to pick among the available allowed contexts (see Switching Context).

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:

<?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_responsible</Privilege>
		<Privilege>urn:dk:sundhed:ehealth:role:treatment_resposible</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>

Had the example instead looked like the example stated above, the user Lasse Dam would have been issued a more narrow JWT as nothing would have been set into context as the AS would be unable to choose between the whether the user should be in the context of the careteam with the role "monitoring responsible" and "treatment responsible" or in the context of the organization with the roles "clinical administrator" (capable of managing PlanDefinition and ActivityDefinitions) and "questionnaire editor".

The PrivilegeGroups provided in the OIO BPP must be unique in accordance with the following scheme:

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

...

The set of services and service operations that the client is authorized to use privileges is conveyed through the Access Token. The set depends on user type and/or federated authentication. The eHealth services perform access control based on the Access Token, often constrained by additional contexts that must be set in the Access Token.

Authorization Based on User Type and Contexts set in the Access Token

The eHealth infrastructure defines the following contexts:

• Organization Context

• Careteam Context

• Patient Context

• Episode of Care Context

Citizen User Type and Contexts

A citizen user type is authorized to see almost all data about the citizen.

This user type will have the Patient Context set.

In general, modifying data requires the Episode of Care Context to be set.

Clinical and/or Administrative Employee User Type and Contexts

...

Citizens

...

...