...
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 RBAC and ABAC rules). Citizens are able to create and edit 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 RBAC and ABAC rules).
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 relations
The above mentioned SAML attributes maps to an internal
Clinical SAML attributes
...
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.
| Attribute | Description |
|---|---|
| urn:oid:2.5.4.10 | Organization name |
| dk:gov:saml:attribute:CprNumberIdentifier | Civil registration number (CPR) |
| dk:gov:saml:attribute:CvrNumberIdentifier | CVR number |
| dk:gov:saml:attribute:RidNumberIdentifier | RID number from certificate |
| dk:gov:saml:attribute:AssuranceLevel | AssuranceLevel (must be 4) |
| urn:oid:2.5.4.3 | Common name (full name) |
| urn:liberty:disco:2006-08:DiscoveryEPR | IDCard |
| dk:healthcare:saml:attribute:HasUserAuthorization | A boolean saying if the user has any healthcare authorizations |
| dk:healthcare:saml:attribute:UserAuthorizations | A list of the users healthcare authorizations |
| http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn | The globally unique ID of the user |
| dk:gov:saml:attribute:Privileges_intermediate | A base64-encoded XML structure in OIO BPP format, listing privileges. If an employee should have any permissions, this attribute should define one or more roles in scope of an organizational unit or careteam, e.g. a SOR number, STS Organisation or careteam reference. See general structure in documentation[1]. [1] https://digst.dk/media/19020/oiosaml-basic-privilege-profile-1_1.pdf |
| dk:healthcare:ehealth:saml:attribute:scopingOIOBPPContext | Optional. Can be used to limit scopes expressed in the OIO BPP structure. This is not yet used and will be ignored. |
The attributes used are the CPR number (dk:gov:saml:attribute:CprNumberIdentifier), the UPN (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn) 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 UPN 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
...
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).
...