Add AuthZ to HAPI FHIR - Part 2
Introduction
This is the second post, in a series of posts about adding support for Authorization (AuthZ) in HAPI FHIR.
- Add AuthZ to HAPI FHIR - Part 1
- Add AuthZ to HAPI FHIR - Part 2
In the first post, we identified some options to enable (fine grained) Authorization (AuthZ) in HAPI FHIR.
In this post we are going to look at Option 1 in more detail.
Option 1
There are three components to this solution: an Identity Provider that authenticates the user; an Authorization Server that decides what a given user can access; and an Access Gateway which enforces those permissions.
- Identity Provider: Keycloak
- Authorization Server: Keycloak
- Access Gateway: FHIR Info Gateway
Keycloak - Authorization Server
We will need to extend Keycloak and add support for SMART on FHIR:
We'll start by adding support for (SMART on FHIR) Backend Services.
Keycloak - Authorization Services
In OAuth 2.0 terms HAPI FHIR is a Resource Server (a server hosting the protected resources and capable of accepting and responding to protected resource requests).
Follow the steps in the Keycloak Authorization Services Guide to:
- Create a client application
- Enable authorization services
- Manage resources and scopes
- Manage policies
- Manage permissions
OAuth2 Scopes
SMART on FHIR defines OAuth2 scopes that correspond directly to FHIR resource types. These scopes impact the access an application may have to FHIR resources (and actions).
SMART on FHIR defines permissions to support the following FHIR REST API interactions:
c
for creater
for readu
for updated
for deletes
for search
Valid suffixes are a subset of the in-order string .cruds
. For example, to convey support for creating and updating observations, use scope patient/Observation.cu
. To convey support for reading and searching observations, use scope patient/Observation.rs
.
See: Scopes for requesting FHIR Resources
Version 26.1.0 - Notable changes
New client scope service_account
for client_credentials
grant mappers.
Keycloak introduces a new client scope at the realm level called service_account
which is in charge of adding the specific claims for client_credentials
grant (client_id
, clientHost
and clientAddress
) via protocol mappers.
This scope will be automatically assigned to and unassigned from the client when the serviceAccountsEnabled
option is set or unset in the client configuration.
See: Version 26.1.0 - Notable changes
I also followed the recommendations in the following guides:
- Keycloak docs: Migrating to Quarkus distribution
- Keycloak docs: Upgrading Guide - 26.1.0
References
OAuth 2.0
- IETF: OAuth 2.0 for Browser-Based Applications
- Spring docs: Implementation Guidelines for Browser-Based Applications
SMART on FHIR
- HL7: SMART App Launch
- SMART Health IT: SMART on FHIR
Keycloak
- Keycloak docs: Authorization Services Guide
FHIR Info Gateway
- GitHub: FHIR Info Gateway