The eHealth infrastructure uses OIOSAML Basic Privilege Profile 1_2 (digst.dk) to express user privileges as attributes in SAML Assertions.

1 Examples of PrivilegeList:
2 Contents of a PrivilegeList
- 2.1 Organization Constraints
- 2.2 Care Team Constraints
- 2.3 Privileges:
3 Acceptance of PrivilegeList

The infrastructure also supports version 1.1, the only difference being the XML namespace of the schema:

Version	Namespace

Version	Namespace
1.1	`http://itst.dk/oiosaml/basic_privilege_profile`
1.2	`http://digst.dk/oiosaml/basic_privilege_profile`

Examples of PrivilegeList:

<?xml version="1.0"?>
<PrivilegeList xmlns="http://itst.dk/oiosaml/basic_privilege_profile">
  <PrivilegeGroup Scope="urn:dk:gov:saml:cvrNumberIdentifier:20921897">
    <Constraint Name="urn:dk:gov:saml:sorIdentifier">eeeeeeee-b760-11e9-a2a3-2a2ae2dbcce4</Constraint>
    <Constraint Name="urn:dk:sundhed:ehealth:careteam">cccccccc-b760-11e9-a2a3-2a2ae2dbcce4</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:20921897">
    ...
  </PrivilegeGroup>
</PrivilegeList>

Example of PrivilegeList without careteam

<?xml version="1.0"?>
<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: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>

Contents of a PrivilegeList

Municipalities MUST follow the guidelines located here: OIO-BPP URI naming precautions for municipalities

A PrivilegeList must contain at least one PrivilegeGroup with Scope="urn:dk:gov:saml:cvrNumberIdentifier:<some number>".

A PrivilegeGroup has the following elements:

Exactly one Constraint specifying an organization identifier (see Organization Constraints)
At most one Constraint specifying a care team identifier (see Care Team Constraints)
At least one Privilege element

Organization Constraints

An organization constraint identifies an Organization resource by an external identifier and type.

There are three types of organizations:

SOR organizations:
- Identified by Constraints with Name attribute = "urn:dk:gov:saml:sorIdentifier" and value = {sor-id}
- Refers to Fhir Organization with Identifier.system = "urn:oid:1.2.208.176.1.1" and Identifier.value = {sor-id}
- Example:
  - Constraint:
    - <Constraint Name="urn:dk:gov:saml:sorIdentifier">950531000016003</Constraint>
  - Refers to Organization with:
STS organizations
- Identified by Constraints with Name attribute = "urn:dk:kombit:orgUnit" and value = {sts-id}
- Refers to Fhir Organization with Identifier.system = "https://www.kombit.dk/sts/organisation" and Identifier.value = {sts-id}
- Example:
  - Constraint:
  - Refers to Organization with:
SSL organizations
- Identified by Constraints with Name attribute = "urn:dk:sundhed:ehealth:sslOrg"
- Refers to Fhir Organization with Identifier.system = "http://ehealth.sundhed.dk/organization/ssl" and Identifier.value = {ssl-id}
- Example:
  - Constraint:
  - Refers to Organization with:

Care Team Constraints

A care team constraint identifies a CareTeam resource by an external identifier.

Care team constraints always have Name attribute = "urn:dk:sundhed:ehealth:careteam".

A care team constraint with value = {careteam-id} refers to Fhir CareTeam with Identifier.system = "urn:ietf:rfc:3986" and Identifier.value = {careteam-id}

Example:

Constraint:
Refers to CareTeam with:

Privileges:

Allowed privileges:

See Token Based Security | Privilege Roles

Acceptance of PrivilegeList

This section describes different scenarios for eHealth Infrastructure acceptance of privilege lists:

In the same <PrivilegeList> there can be both valid and invalid PrivilegeGroups. The valid ones will still be able to be used even if the list also contains invalid ones.

The invalid group will be in a list of "warnings" in the response from Keycloak's /contexts endpoint to the calling system.

	Scenario	Handling

	Scenario	Handling
1	Referenced Organization does not exist in the eHealth Infrastructure Example `Scope="urn:dk:gov:saml:cvrNumberIdentifier:20921897"` cannot be found.	The entire `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.
2	Unknown privilege in privilegegroup. Eg. group contain privilege like `<Privilege>urn:dk:kombit:system_xyz:view_case</Privilege>`	The entire `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.
3	Unknown <Constraint> in <PrivilegeGroup> E.g. `<Constraint Name="urn:dk:kombit:KLE">25.*</Constraint>`	The `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.
4	Referenced CareTeam does not exist	The entire `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.
5	Referenced CareTeam is not active	The entire `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.
6	Refrence CareTeam “from date” is in the future.	The `<PrivilegeGroup>` becomes a valid context in Keycloak's `/contexts` endpoint
7	Referenced sorIdentifier does not exist `<Constraint Name="urn:dk:gov:saml:sorIdentifier">eeeeeeee-b760-11e9-a2a3-2a2ae2dbcce4</Constraint>`	The entire `<PrivilegeGroup>` is ignored. Other `<PrivilegeGroup>` are handled.