Stream: smart
Topic: Resolving FHIR-32251
Josh Mandel (Aug 09 2021 at 21:08):
We talked through but didn't reach a resolution for FHIR-32251 on today's call. Based on the current resolution so far we've heard:
- "I really like the resolution in FHIR-32251. Hopefully, it'll help to make users aware that we are talking about different layers here." (@Alexander Zautke)
- Especially for non-experts, this proposal is hard to understand (@Christiaan Knaap)
Anybody else have a perspective? I think the basics we want to convey are:
- App approvals can be made by a user, or by a pre-configured system policy
- Scopes granted are always limited by the underlying permissions of that user or pre-configured policy; scopes don't tell the "full story" of what's allowed, but rather they tell the "delegation story" of what's being shared with an app
- Having a given scope granted (e.g.,
user/*.c) doesn't mean that every "write" operation will succeed; all kinds of business rules may prevent an app from writing data (e.g., invalid data like a MedicationRequest with an invalid drug code; or data that a user isn't authorized to submit, like a patient app trying to add a new PractitionerRole for an existing Practitioner).
Josh Mandel (Aug 09 2021 at 21:08):
I'd love suggestions or feedback before next week's call, so we can work on this asynchronously and come to the FHIR-I meeting with a plan.
John Moehrke (Aug 09 2021 at 21:21):
I like the comment by Geno that the SMART specification should always be clear that a server can further refine the restrictions. This has always been true, right? The granularity available in the SMART scope specification is not ever going to be as potentially refined as needed, but it is always evolving to more fine grain. The hope is that the graininess is good enough to inform the communication pathway without getting in the way of actual policy.
Josh Mandel (Aug 09 2021 at 21:35):
Yes, a server can always impose restrictions not expressed in scopes, and this can be silent (e.g., redacting some search results without making this known) or loud (e.g., refusing to accept a write request). This particular issue was about writes; we've addressed the question about reads at https://jira.hl7.org/browse/FHIR-32250
Alexander Zautke (Aug 12 2021 at 13:16):
@Christiaan Knaap Does your comment focus on the language of the proposed resolution or is it the fact that a granted wildcard scope may not result in a successful interaction?
Alexander Zautke (Aug 12 2021 at 13:32):
One part that might lead to confusion is the following part "For example, a user can't grant permission she does not have [...]". The user can grant the scope (user/*.c in this case), but can't the permission. Not sure how to reword the sentence, but I would avoid "grant" in this context.
Josh Mandel (Aug 12 2021 at 13:58):
Could write "give" or "convey" here to avoid overloading this term.
Christiaan Knaap (Aug 16 2021 at 09:51):
@Alexander Zautke : It was about the language / wording of the solution.
The 3 bullets and Johns wording above make it more clear already - maybe we can take that as a basis for the wording in the spec.
Josh Mandel (Aug 16 2021 at 18:24):
Thanks for the feedback on this -- I've updated the proposed resolution to take this into account, and would love your take @Christiaan Knaap . Does the rewrite help?
Christiaan Knaap (Aug 17 2021 at 07:28):
Thanks for the rewrite @Josh Mandel . It helps. Nevertheless I tried to rewrite it further to avoid the notion of 'underlying'. And I would put it after the listing of the scopes, so we can refer to them after they are introduced. My try:
A client application requests data from a resource server. It presents an access token having scopes. These scopes convey the actions a user authorizes the client to do on his/her behalf. The resource server can use these scopes as input to its decision to authorize the request fully, partially or not at all. The authorization can be viewed as a 4 step filter:
- The client application requests a set of scopes. It should only ask for the minimum set of scopes needed for its operation, but the client cannot be enforced to do so.
- The authorization server may alter this to a set of scopes the user is allowed to grant. So the user cannot allow the client application to do anything beyond his/her own authorization. Company policies, authentication strength, user roles and other data can be factors here.
- The user may choose to grant the client only a subset of the requested scopes. E.g. a client may by default ask for patient/cruds, but the user intends to use the app only for reading and thus only grants patient/rs.
- The resource server may apply additional policies to further restrict access. E.g. it may filter out data of VIPs or certain conditions, or disallow an update to an Observation that has a status of 'final'.
Note that the policies, roles and other forms of permissions used in the either the authorization server or the resource server may not all be expressable in SMART on FHIR scopes or any construct in the FHIR Core specification itself.
As a result, a request by a client to a resource server can be:
- fully allowed
- partially allowed, e.g. a search may have results omitted, even silently
- disallowed - because of step 4 above this can happen even if the granted scopes indicate that the request should be allowed
Christiaan Knaap (Aug 17 2021 at 07:34):
Oops, I only now see that the issue has been resolved yesterday. I'm afraid 8:30 PM was a bit too late for me to react in time for the meeting.
Josh Mandel (Aug 17 2021 at 13:16):
Appreciate the notes here -- briefly, I really liked the language we arrived at re "underlying" permissions, on the call yesterday, including 1) the fact that such underlying systems exist, and 2) the fact that they're out of scope for SMART and for FHIR Core. Also looking at the language you proposed above, I don't think it's a strict "filter" process; during the negotiation scopes can be added or broadened as well.
If you want to reopen the issue, we have a process for voting to do so; personally I think we have landed in a good place after substantial discussion.
Michele Mottini (Aug 17 2021 at 13:26):
(Minor: If search results are omitted due to security reason it will always be silently...)
Josh Mandel (Aug 17 2021 at 13:29):
We don't say whether it will be silent or not, and I think that's a good thing because I'm not sure it will always be silent @Michele Mottini -- like epic has an OperationOutcome in most search API responses indicating that they may not be complete; I could "hear" this as a non-silent note about omissions related to security.
John Moehrke (Aug 17 2021 at 13:29):
not always.. but most of the time. There are some users that are privileged enough to know that data are being blinded to them, usually these users are those that are privileged enough to "break-glass".
John Moehrke (Aug 17 2021 at 13:30):
http://hl7.org/fhir/security.html#AccessDenied
Last updated: Apr 12 2022 at 19:14 UTC
