Stream: implementers
Topic: Is an OperationOutcome expected with a 401/403?
Ardon Toonstra (Jan 05 2021 at 12:25):
Does the FHIR spec require the return of an OperationOutcome when a search is performed with incorrect authorization? Considering these specs, http://hl7.org/fhir/http.html#search : “If the search fails (cannot be executed, not that there are no matches), the return value return value SHALL be a status code 4xx or 5xx with an OperationOutcome.”
Perhaps that's me interpreting this to literal, as in https://www.hl7.org/fhir/http.html#Status-Codes it is stated this an OperationOutome is not always required.
René Spronk (Jan 05 2021 at 12:37):
At the very least it's a SHOULD, and from a error handling perspective I can certainly see why a SHALL is in order. The alternative is that one only receives a HTTP status code, which is too minimalistic for most purposes.
Ardon Toonstra (Jan 05 2021 at 13:08):
The argumentation for not returning a OperationOutcome would be that it will likely not contain additional information next to the HTTP status code and the authorization checks might be performed by a generic security framework before the FHIR server is given the request. Which are two valid points I guess. I am however a little confused by the expectations of the FHIR spec about this.
René Spronk (Jan 05 2021 at 14:30):
At least the NHS is pretty clear about this: https://nhsconnect.github.io/FHIR-SpineCore/resources_error_handling.html "In the event of an error, provider systems SHALL respond by providing an OperationOutcome resource"
Vadim Peretokin (Jan 05 2021 at 14:53):
I think that while it says it is not always required, in this case - it is.
Michele Mottini (Jan 05 2021 at 15:34):
SHALL is too strong for exactly the reason Ardon states: permission checks could be done by non-FHIR subsystems that do not know anything about FHIR
Michele Mottini (Jan 05 2021 at 15:36):
...and a 401 or 403 are already pretty explanatory on their own
René Spronk (Jan 05 2021 at 15:44):
for non-FHIR aware systems, RFC 7807 would apply .. especially if there was no Accept header which indicated support for FHIR.
Lloyd McKenzie (Jan 05 2021 at 15:53):
Certainly we should clarify the wording. Can you submit a change request?
Ardon Toonstra (Jan 05 2021 at 16:36):
I would happily create a ticket. But I am not completely sure if the consensus is to make it more clear that an OperationOutome is expected or not.
Lloyd McKenzie (Jan 05 2021 at 16:43):
The work group will need to decide. My opinion is that there's no reason to force an OperationOutcome to be provided
Ardon Toonstra (Jan 05 2021 at 17:16):
Done: https://jira.hl7.org/browse/FHIR-30240
Grahame Grieve (Jan 05 2021 at 21:01):
certainly the intent is that if a resource is returned, it SHALL be an operation outcome
Frank Oemig (Jan 08 2021 at 07:51):
With the original request you are approaching a FHIR endpoint. Even if a preprocessing security check fails what is the reason for not drafting a proper FHIR result if we are looking for FHIR conformance?
Lloyd McKenzie (Jan 08 2021 at 14:28):
It only makes sense to return a resource if you've got something useful to say. Quite often when the issue is a security violation, it's good practice to say as little as possible - to provide minimal surface area for an attacker to probe. So if the only information you want to convey back to the client is "you don't have permission", then there's no value in sending anything other than a bare 403.
Michele Mottini (Jan 08 2021 at 15:17):
what is the reason for not drafting a proper FHIR result
That the pre-processing system doing the security checks does not know anything about FHIR
John Moehrke (Jan 08 2021 at 15:20):
yes, common in cloud systems TLS and OAuth are handled (to some degree) by dedicated general IT systems. THEY will not understand FHIR.
John Moehrke (Jan 08 2021 at 15:21):
they don't need to understand FHIR to reject the request for security reasons
John Moehrke (Jan 08 2021 at 15:21):
load ballancing also... not FHIR knowledgable
John Moehrke (Jan 08 2021 at 15:21):
thus clients need to be told that sometimes failures will be reported without a OperationOutcome
Daniel Venton (Jan 08 2021 at 18:25):
Absolutely, the clients always have to expect that occasionally they are not going to get an operation outcome resource. Based on network configuration with proxies, custom DNS, custom routes and gateways, it's entirely possible that the client will receive a 200 or any other https status with no body at all. But in the examples of a LB or authentication processors, it's likely they have the ability to return custom pages (resources) for any status.
In short: The client should always prepare for the situation that they might not get a resource. The servers should do their best to always return a resource (error or otherwise).
Lloyd McKenzie (Jan 08 2021 at 19:27):
They should return a resource if they have something useful to say. Returning an OperationOutcome that doesn't communicate anything more than the HTTP code is unnecessary overhead.
Last updated: Apr 12 2022 at 19:14 UTC
