The documentation on this page is currently in an unreviewed state.
Access to data in the the eHealth Infrastructure is governed by its provided Authorization Server (AS). The AS is responsible for handing out tokens that are properly signed with the correct level of detail embedded. Without a token, no access is provided. The eHealth Infrastructure is by intend and design not part of any other existing infrastructure such as the NSP - instead, it integrates to a range of services (among these is services on the NSP).
The eHealth Infrastructure does not provide an IdP meaning that no users by design exists in the infrastructure. Instead, the AS is federated with two services that provides the identity of the users:
NemLogin
NemLogin uses NemID in order to provide the services needed as an IdP endpoint. The NemLogin service is intended to be used by citizens in order to gain access to data in the eHealth Infrastructure.
SEB
SEB is a common platform for user administration of the solutions provided by the National Board of Health Data on both the Internet and the proprietary Sundhedsdatanettet. SEB is based on a platform that takes into account OIO standards in this area. SEB provides a federation with the regional instances and municipality instances (how this federation is constructed is beyond the scope of the eHealth Infrastructure).
In the relation to the eHealth Infrastructure, SEB primarily serves two purposes:
- Provide a homogenous interface from its federated IdP's towards the eHealth Infrastructure
- Doing the actual federation between the regional instances and the municipality instances
eHealth Infrastructure federation
Login flow
The AS supports login using OpenID Connect "code flow" while NemLogin and SEB supports OIO SAML. The AS bridges these security flows by sending back a redirection if no token is provided when interacting with the eHealth Infrastructure (NemLogin and SEB each have their own security realm in the AS meaning that the redirection logic is unambiguously). The sequence of redirects (and SAML AuthRequests/Responses) that takes place between the app and its federated endpoint, before the AS is finally invoked with a SAML AuthResponse, is unknown to the eHealth Infrastructure (but in the case of SEB, it probably involves redirects from SEB back to the users own IdP and back again). See Login for details.
While NemLogin provides details on the identity of the citizen such as name and civil registration number, SEB also provides details on the user in regards to what roles that apply. It is unknown to the eHealth Infrastructure how and when these roles are applied in the federated setup (a qualified guess would be that they origin from the IdP).
As no roles are issued from NemLogin, it means that citizens by default can only read data marked as theirs/involving them, with a few exceptions. Users (clinical users) however are provided with roles (from SEB or the IdP) scoped within an organization or a careteam (a careteam, in short, is a set of clinical users that provides services to a citizen. Users in careteams are not restricted to origin from the same region/municipality). Users can be in multiple careteams at the same time.
In order to provide a stateless and scalable setup while at the same time comply with the requirements of the eHealth Infrastructure the following security mechanisms come into play:
Token based security
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 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. Possible contexts are
- Episode of care
- Patient
- Organization
- Careteam
Each time one or more of these context items are provided in the step where the user chooses a given context, a consistency check is made in the eHealth Infrastructure order to check that the chosen set of context items actually fit together. All in all, without going into details it can be stated that the security model does both RBAC and ABAC security checks.
Detailed parts of the security documentation can be found at the following pages: