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.

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.

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 create
  • r for read
  • u for update
  • d for delete
  • s 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:

References
OAuth 2.0
SMART on FHIR
Keycloak
FHIR Info Gateway