Page Comparison

...

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 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 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. 

...

The structure of the OIO BPP 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 context description). If the user is only part of a single careteam, it is automatically set in context. Switching 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)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 PriviledgeGroups 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 ABAC and RBAC rules.

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.

...