| Table of Contents |
|---|
Client to the ehealth infrastructure should Before a client system can interface with the eHealth Infrastructure a set of items must be carried out and complied with:
- A client application to the eHealth Infrastructure must implement an OpenID Connect "code flow" in order to login and get a set of tokens.
...
...
- A client application must be created and setup in the login server and assigned a name, and the URL's used to redirect back to the client must be whitelisted.
...
- A client can be either confidential (like a server application) or public (like an app or a web application). Confidential clients authenticate themselves with a password. Public client must use PKCE (pronounced "pixi"). Explanations can be found many places, for instance here and here.
The loginserver of the infrastructure Having completed these bullets, the Authorization Server (AS) will delegate parts of the login to potentially other federated servers, but that is transparent for the client (provided the login is handled by a generic browser window that can handle redirects).
Client types
Clients come currently comes in two flavors. EmplyeeClinical- and citizen clients. Each type uses it's its own login flow and realm which results in two authorization url's (please see the section LoginAuthorization Server for further information).
As a result: If clients (and server applications) handles both employee clinical and citizen users, then token validation must be able to handle multiple certificate url's.
Example of certificate url's for the inttest environment:
- EmployeeClinical users: https://saml.inttest.ehealth.sundhed.dk/auth/realms/ehealth/protocol/openid-connect/certs
- Citizen: https://saml.inttest.ehealth.sundhed.dk/auth/realms/nemlogin/protocol/openid-connect/certs
...
Clinical logins
For employees clinical client applications it is expected that the total login flow will look somewhat like this. Details can vary depending on the organization of the user (region , municipality or service/support/logistics organizationor municipality).
Citizen logins (first time)
For citizens, a similar login flow could look like this:
Authorization Server
Current active environments:
EmployeeClinical:
Base url: https://saml.${environment}.ehealth.sundhed.dk/auth/realms/ehealth
...
- https://saml.inttest.ehealth.sundhed.dk/auth/realms/nemlogin
- openid-configuration
- NOTE: Nemid federation is not currently configured - expected withing the first one or two weeks of September.
Client Adapters
Keycloak (being the AS) has an extensive set of client adapters (libraries) for usage on various platforms and programming languages:
...
If, for some reason, you can't use a keycloak client adapter - here is an example URL for an authentication request using HTTP GET, written in a readable format is shown below. It should be sent as a single line without spaces or newlines.
...
When the authentication is complete, the browser is redirected back to the given "redirect_uri" (which must be whitelisted in the Authorization ServerAS) including a "code" as a request parameter. This code must be used when calling the token endpoint afterwards.
Example token exchange
Here is an An example of the following POST request to obtain a context aware access token is shown below.
| Code Block | ||||
|---|---|---|---|---|
| ||||
POST /auth/realms/ehealth/protocol/openid-connect/token HTTP/1.1 Content-Type: application/x-www-form-urlencoded grant_type=refresh_token& refresh_token=<refresh_token>& client_id=<client_id>& client_secret=<client_secret>& organization_id=<organization_id>& care_team_id=<care_team_id>& patient_id=<patient_id>& episode_of_care_id=<episode_of_care_id> |
The first four parameters are required, and the remaining are optional. 'organization_id' and 'care_team_id' can be used individually or in combination. 'patient_id' and 'episode_of_care_id' can also be used individually or in combination, but requires that 'care_team_id' is also present. More details on context switching can be found at Switching Context.