Authentication and authorization

The documentation on this page is currently in an unreviewed state.

The infrastructure provides a login component, which is the client systems' access to user authentication and authorization. This functionality is implemented in the Authorization Server. The login protocol between the client systems and the login component will follow the standard OpenID Connect. Authentication should be done by completing an OpenID Connect "code flow".

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 (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 all data to whom they are referenced (see ABAC rules). Citizens are able to create and edit data in the eHealth Infrastructure according the RBAC rules.
• Clinical users are able to access

two paths where one path is . is is primarily based upon the affiliation to a given careteam and the role in that given careteam. This 

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 relations

The above mentioned SAML attributes maps to an internal 

Clinical SAML attributes

OIO BPP in the eHealth Infrastructure

The structure of the OIO BPP is capable of expressing multiple careteam- and organization affiliations.

In the case where the user is part of multiple careteams (stated in the OIO BPP as part of the SAML AuthResponse), the user needs to set the wanted careteam in context (see context description). If the user is only part of a single careteam, it is automatically set in context. Once a careteam is set into context (see context switching), the set of roles changes in the returned access token and provides the user with a different set of accessibility to the data within the eHealth Infrastructure. The set of items that can be set into context are: Organization, Patient, CareTeam, EpisodeOfCare (see context switching). As such, the eHealth Infrastructure governs the access to data using both RBAC (stated roles from login) and ABAC (asserting data attributes on the actual content).

Clinical client systems avoid the complexity associated with user registration and resumption of sessions based on pin code or biometric data. It should not be supported for clinical users.

On the other hand, there is a need for strict management in relation to the context in which the user works, so that there is no potential for the systems to mix data together that relate to different patients / citizens. Therefore, it will be require exchanging AT or RT to a new AT that is context-specific and where the user's rights in the specific context have been evaluated.

Roles and permissions