...
Once the user is logged in, a set of tokens (see Authentication and authorization for details on the tokens) are handed out by the AS (based on the OIO SAML AuthResponse). These tokens servers serve as 'tickets' and are verified and asserted every time the user interacts with the eHealth Infrastructure. If deemed invalid or expired by the eHealth Infrastructure, no further interaction happens and the user is denied from accessing or manipulating data. As the tokens from the login initially are very broad spectred, little or no data is accessible. This entirely depends on the information given in the OIO SAML AuthResponse. If the user e.g. happens to be part of multiple careteams, the AS is unable to supply proper default values as the choice is not unambiguously. This is due to the fact that the access to data under each careteam may differ from careteam to careteam. In order to actually gain access to eg. clinical or organizational data, the user needs to actively choose in which context the user wants to interact. Based on the choice of context, the eHealth Infrastructure can forge a new set of tokens (based on the initial handed-out tokens + the chosen context - see Switching Context for details) which then provides access under the given chosen context.
...
Besides granting access to organizational data, the Organization-context is also used for audit logging and the national NSP service, MinLogMinLog2.
The Access Token
When a user is logged into the eHealth Infrastructure a set of tokens are issued to the user. The Access token is explained in further detail in this section.
The Access token is a JWT with at a set of fields that explains explain what a user is allowed to do in combination with the applied context. The fields of the JWT are the following:
...
What operations that the user is allowed to do is stated in the "realm_access" attribute. In the example above the user is allowed to issue a "Patient.read" and a "Patient.write". This means that the user can get and edit patient records. This part of the security model is the RBAC-part, as the claims here are entirely based upon what role the user has. Each resource type (see https://docs.ehealth.sundhed.dk/latest/ig/profiles.html) has certain restrictions to what context must be issued, in order to allow data retrieval or data manipulation. This is stated in the Access rights section below (For instance, in order to either read/search or write to a patient, the patient must be in context). Furthermore, the context attribute shows what data is in context. The set of items that can be set into context are : Organization, Patient, CareTeam, EpisodeOfCare (see Switching Context). As such, the eHealth Infrastructure governs the access to data using both RBAC (stated roles from login) and ABAC (asserting data attributes on the actual content).
...
Privilege roles are the roles that are part of the issued OIO BPP. These roles SHALL match the roles stated in the AS. The AS is the master data repository of the privileges privileged roles. Roles issued in the OIO BPP that does do not match the roles defined in AS are ignored.
The current list of privilege roles defined is as given in the table below.
...