Authorization errors should return OperationOutcome resources about fhir-works-on-aws-routing HOT 4 CLOSED

👍 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

from fhir-works-on-aws-routing.

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

from fhir-works-on-aws-routing.

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?

from fhir-works-on-aws-routing.

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.

from fhir-works-on-aws-routing.