The documentation on this page is currently in an unreviewed state.
...
The eHealth Infrastructure does not provide an IdP meaning that no users by design exist in the infrastructure. Instead, the AS is federated with two services that provide the identity of the users:
...
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 not of concern 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 (the authentication part), SEB also provides details on the user in regards to what roles that apply (both authentication and authorization). It is unknown to beyond the scope of 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. It is expected that the authorization part is governed by the IdP itself).
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.
...