Authorization errors should return OperationOutcome resources

[Dunmail]

HTTP 403 responses have a proprietary JSON body rather than a FHIR OperationOutcome resource.

Impacts

• A FHIR client expecting a FHIR resource may not correctly interpret the response
• This will force refactoring if content types other than JSON are used in the future (e.g. XML, RDF)

Source
Source: https://github.com/awslabs/fhir-works-on-aws-routing/blob/mainline/src/app.ts
Commit: d120da1

When the authorization.isAuthorized function returns false or throws an error (ln45) a response is provided directly (ln52, ln55)

A possible solution is to throw an http error which can be caught as an http error and wrapped in an OperationOutcome in the error handler: https://github.com/awslabs/fhir-works-on-aws-routing/blob/mainline/src/router/routes/errorHandling.ts.

[rsmayda]

Hey Dunmail! Thanks for opening this -- good callout. Looking at the FHIR spec the part we are hung up with is:

On the RESTful interface, operation outcome resources are only relevant when a level of computable detail is required that is more granular than that provided by the HTTP response codes. This granularity could include:

• more detail about the location of an issue
• the ability to identify multiple distinct issues
• provision of finer error codes that connect to known business failure states

https://www.hl7.org/fhir/operationoutcome.html#using

The "computable detail is required that is more granular than that provided by the HTTP response codes" does not seem relevant for 403 errors as we would want to maintain a generic 403 for all possible 403 permutations (for security reasons).

Though there is probably a benefit for a consistent 'error' experience from a client perspective. Out of curiosity do you have clients that require errors to produce OperationOutcomes?

[Dunmail]

Hi Robert,

I do agree with the principle that opaque security errors are a good thing for production systems. However, we have production use cases where limited supplementary information can help the users distinguish different modes of failure.

For example, we have a service providing patient search on the NHS MPI. Requests can generate a 403 response for different business reasons:

• Your role isn't allowed to search for Patients
• Your organization isn't allowed to use the NHS PDS service

It's also really useful to share information in development systems so that the client can be given detailed information about why their request has been rejected.

From a client perspective the consistent error experience is important. Our current apps and services use either UI controls to render an OperationOutcome or write to logs in a known format.

[rsmayda]

👍 This context helps for sure. I will add it to our backlog on our side. Rough work required:

• change interface from returning a boolean to void and the contract is to throw an AuthZ error if validation fails
  • https://github.com/awslabs/fhir-works-on-aws-interface/blob/mainline/src/authorization.ts#L31-L35
• The thrown error should be caught within the errorHandling but there may need to be some additions here too: https://github.com/awslabs/fhir-works-on-aws-routing/blob/mainline/src/router/routes/errorHandling.ts

[rsmayda]

Forgot to tag this issue; we completed this on Nov 12th; for code see: https://github.com/awslabs/fhir-works-on-aws-routing/blob/mainline/src/router/routes/errorHandling.ts#L33 or commit: 4c5c310#diff-86a044095555cf0881c9677d5b42481ee07a05d2f394e442d57984966e08ce91