Authorizing Resource Access

Explains what systems are involved in accessing resources through Nuts and how access is authorized. It also details example deployments.

Overview (WIP)

When a (care) organization (client) wishes to exchange data with another (care) organization (resource owner) through Nuts, they agree on common technology: OAuth2, DIDs, Verifiable Credentials and Presentations and use case-specific (e.g. eOverdracht) API standards (typically HL7 FHIR).

Resource access authorization is consists of 2 parts:

Components

API Gateway

This setup deploys an API Gateway to secure access to the resource server. API Gateways are typically used to route/load balance incoming requests, monitor traffic and secure endpoints. Most off-the-shelve (e.g. Kong, APISIX, NGINX Plus) products support the required standard authorization protocols (RFC7662 OAuth2 Token Introspection) and commonly used products for authorizing access (e.g Open Policy Agent).

Although a Policy Enforcement Point (PEP) should be part of the resource server, it can be offloaded to the API Gateway if the connection between gateway and resource server is secured sufficiently to avoid man-in-the-middle attacks.

Policy Decision Point

There are 2 types of OAuth2 access token scopes;

When wide/conceptual scopes are used, additional authorization is required when clients attempt to access a specific resource (e.g. /fhir/Patient/12345). This request authorization is performed by the Policy Decision Point that makes a decision based on the access attempt, OAuth2 access token (containing user information and scope) and often additional ACL-like information.

Example: eOverdracht

For example, given the eOverdracht use case:

Implementation: APISIX and Open Policy Agent (WIP)

This implementation shows authorization can be implemented with freely available open source products:

You can find an example of this deployment at https://github.com/nuts-foundation/nuts-workshops/tree/master/deployments/api-gateway.

Use Case Design Guidelines (WIP)

The way authorization is designed in a use case influences the effort it will take to implement it.

A use case can restrict access

Scopes

Policies

Authorization policies should require as

Anti-patterns