| Excerpt |
|---|
Description of This page describes the required SAML attributes in the tokens for municipal and regional users. |
| Table of Contents |
|---|
Common for both municipal and regional users is that:
Municipal and regional users' access to the eHealth Infrastructure goes through SEB.
The Infrastructure Authorization Service (AS) redirects a login to SEB (as SAML AuthNRequest to SEB).
SEB forwards redirected the SAML AuthNRequest to municipal and regional Identity Providers (IdP), respectively.
As apparent in From the SEB there are differences in what systems are involved in the login flow.
Federated Authentication and Authorization for Municipal Users and describes the flow for municipality users.
Federated Authentication and Authorization for Regional Users there are differences in what systems are involved.
describes the flow for regional users.
The SAML AuthNResponse returned to the SEB and the Infrastructure AS is a SAML AuthNResponse conforming must conform to OIO BPP
| Info |
|---|
Technically speaking, authorization is performed in the Infrastructure Authorization Service while the municipal and regional IdP provide claims. In effect, however, the IdPs provide the decisions behind the authorization in the form of system roles. |
...
SAML Attributes
...
for Clinical Users
The SAML AuthNResponse from the SEB shall contain SAML attributes in a SAML assertion which is used the eHealth Infrastructure uses to identify the clinical user.
Attribute | Description | ||
|---|---|---|---|
| Organization name | ||
| Required from SEB. Civil registration number (CPR) | ||
| CVR number | ||
| RID number from certificate | ||
| AssuranceLevel (must be 4) | ||
| Required from SEB. Common name (full name) | ||
| IDCard | ||
| A boolean saying if the user has any healthcare authorizations | ||
| A list of the users healthcare authorizations | ||
| Required from SEB. The globally unique ID of the user within his/her organization. (also known as UID) | ||
| Required from SEB. 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 | ||
| Optional. Can be used to limit scopes expressed in the OIO BPP structure, by adding it as a constraint in each PrivilegeGroup. Only PriviledgeGroups with the constraint matching the value of scopingOIOBPPContext will be available for the user.
|
The required attributes used are the CPR number (:
dk:gov:saml:attribute:CprNumberIdentifier
...
- the CPR number is primarily used for delivering data to the central NSP MinLog2 service.
...
urn:oid:0.9.2342.19200300.100.1.1the UID uniquely identifies the user in the eHealth Infrastructure
...
dk:gov:saml:attribute:Privileges_intermediateprovides the user's roles and the careteams that are
...
available to the user in the OIO BPP format.
OIO BPP in the eHealth Infrastructure
| Note |
|---|
Municipalities MUST follow the guidelines located here: OIO-BPP URI naming precautions for municipalities |
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 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 apply to the user - expressed in the JWT (the internal access token of the eHealth Infrastructure).
An example:
OIO BPP
| Code Block | ||
|---|---|---|
| ||
<?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> |
...
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
| Code Block | ||
|---|---|---|
| ||
<?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> |
...
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.