Common for both municipal and regional users is that:

1. Municipal and regional users' access to the eHealth Infrastructure goes through SEB.

2. The Infrastructure Authorization Service (AS) redirects a login to SEB (as SAML AuthNRequest).

3. SEB redirected the SAML AuthNRequest to municipal and regional Identity Providers (IdP), respectively.

   1. From the SEB there are differences in what systems are involved in the login flow.

   2. Federated Authentication and Authorization for Municipal Users describes the flow for municipality users.

   3. Federated Authentication and Authorization for Regional Users describes the flow for regional users.

4. The SAML AuthNResponse returned to the SEB and the Infrastructure AS must conform to OIO BPP

Clinical SAML Attributes

The SAML AuthNResponse from the SEB shall contain a number of SAML attributes in a SAML assertion which the eHealth Infrastructure uses to identify the clinical user.

The attributes used are

1. the CPR number (dk:gov:saml:attribute:CprNumberIdentifier),

2. the UID and

3. the OIO BPP format (dk:gov:saml:attribute:Privileges_intermediate).

The CPR number is primarily used for delivering data to the central NSP MinLog2 service.

The UID uniquely identifies the user in the eHealth Infrastructure T

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 the user's context. 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 apply 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_assistor</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_assistor" 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 straightforward 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:

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_assistor</Privilege>
	<Privilege>urn:dk:sundhed:ehealth:role:citizen_enroller</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 whether the user should be in the context of the careteam with the role "monitoring assistor" and "citizen enroller" 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 by 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.