Stream: implementers
Topic: Resource-level authorization/filtering
Karl M. Davis (Feb 21 2019 at 14:06):
Howdy, all!
Just wondering if anyone has OPINIONS on how this best ought to be implemented on our side:
- We need to start filtering out certain ExplanationOfBenefit resources for certain peers/queries (filtering out SAMHSA-related claims).
- The peers are trusted, so we could just ask them to add an HTTP header or URL query param, but I don't know if/how that fits in to the FHIR spec at all.
- We're using HAPI (not the JPA layer, though), so we could go investigate whatever options it offers for resource authorization and see if that's workable.
* But, our authentication is using mutual TLS and having quite gotten the principals visible in the app layer yet. I can fix that, probably.
I'm inclined to add a query parameter for right now, e.g. nonSamhsa=true, but like I said: curious if anyone has OPINIONS about that. This is all internal usage, so FHIR spec compliance is a nice-to-have, but also not a huge priority.
Thanks!
John Moehrke (Feb 21 2019 at 14:10):
So you are using mutual authenticated TLS... the server thus knows who the client is... so what more is needed for the server to understand the rule distinction? I presume that some clients will get everything others will get a subset... is that what you are looking for?
I would not use parameters, they are not 'secure'... however if a client is found, during an audit analysis, to be misbehaving then you know who to punish... You are doing good audit logging, possibly using AuditEvent... right?
John Moehrke (Feb 21 2019 at 14:11):
Confirming, you are not using OAuth?
Karl M. Davis (Feb 21 2019 at 14:12):
Typo above: _haven't_ quite gotten the principals visible in our app layer.
Grahame Grieve (Feb 21 2019 at 21:12):
there's no particular spec statement on this, so no compliance issues.
Opinions:
- you should default to not sending, and only send when asked (instead of the opposite, which is what you appear to choose).
- you can choose to do it by parameter, by header, or configuration. choosing the last is a fucntional question - better if you can, but not always possible. parameter vs header - I'd probably lean towards a parameter, except:
- this feels like it overlaps with Consent. Is it per-user? Should look at using X-Consent header?
Karl M. Davis (Feb 21 2019 at 22:20):
Excellent advice!
We're a bit constrained by this being 1 of 3 active peers we have, and the only one that needs this filtering. So I'm inclined to make it opt-in for now, just to avoid accidental breakage.
It's less of a consent thing, and more of a policy thing: "not per-Patient, but instead per-peer/user/system -- this peer/system can see SAMHSA claims for any Patient, but this one can't." I'll look into X-Consent, though, to see if that's a reasonable stretch of its use case.
And agreed: definite preference is for configuration (security roles). Just need to get our app server to play ball, which will likely take more time than I have. (Been banging on Wildfly about it occasionally for like a year now.)
Mohammad Jafari (Feb 24 2019 at 21:27):
@Karl M. Davis
If this is something that could become necessary for other partners or in other forms in future, it would be advisable to make it a configurable part of your authorization policy. If you add support for redaction obligations in your authorization policy, i.e. the ability to express a rule to grant access conditioned on applying an obligation, this case then seems to be a redaction obligation applied to all access requests from that particular partner.
I have discussed some more implementation considerations and alternatives for redaction policies here.
Last updated: Apr 12 2022 at 19:14 UTC
