Page Comparison

...

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.

...

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

...

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

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

...

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

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

...