...
- Citizens are able to see almost all data to whom they are referenced (see Tokens, roles 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 Roles and RBAC/ABAC).
The rules that apply are determined by the SAML Assertion when logging in. The SAML attributes are described below.
...
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 Roles and RBAC/ABAC.
Enhanced example:
...
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.
Result and impact of successful login
Clinicians
Whenever clinicians passes a successful loginflow the data from the SAML assertion is parsed and converted to the matching FHIR resources Practitioner, PractitionerRole and CareTeam which are updated in the infrastructure. This means that clinicians (FHIR Practitioners) will be present after login. This also means that clinicians that haven't logged in, won't be present as FHIR resources. Besides the creation and update of the FHIR resources, the loginflow also results in short lived session within the AS (Keycloak). The lifetime of the Keycloak session follows the lifetime of the Refresh Token.
Citizens
Citizens that logs into the infrastructure using NemID are looked up as FHIR Patient resources with the social security number found in the SAML assertion. If a match is found, the FHIR Patient resource ID will be present in the Refresh Token handed back to the client. If no match to a FHIR Patient resource is found, no FHIR Patient resource ID will be present in the Refresh Token. This means that citizens that are not part of any treatment in the infrastructure will be allowed to login, but won't have any rights to read or write any data.