Stream: Security and Privacy
Topic: Security Appliances and FHIR Servers
Grahame Grieve (May 13 2019 at 05:42):
Someone asked me last week about Security Appliances, and how useful they are for FHIR interfaces on EHRs
Grahame Grieve (May 13 2019 at 05:43):
so: http://www.healthintersections.com.au/?p=2945
Grahame Grieve (May 13 2019 at 05:43):
comments from the post are invited here...
Nick Hatt (May 13 2019 at 12:19):
The places where you describe the facade service/api gateway inspecting responses to filter content doesn't sit right with me. 1) It's easier to focus on a uni-directional flow of a request vs. developers thinking about separate inbound vs. outbound logic. 2) Each layer of the web request stack should not need to know about the layer underneath kind of like the OSI model. The gateway needs to know about HTTP(s), what headers to look at, and how to validate an access token. Leave Resource-based security checks to a lower level.
Grahame Grieve (May 13 2019 at 12:21):
they don't sit right with me either - I would never do that myself. But plenty of implementers are doing so
John Moehrke (May 13 2019 at 13:13):
The concept you mention is indeed common in a server side api gateway. I was confused as I was thinking you were describing a client-side model. I would differentiate this rules layer, which is FHIR Resource and Query parameter aware, from the more defensive layer further out that is protecting against more raw attacks. This further out layer can address more course grain decisions that don't know about FHIR Resource or Query. Each layer addresses a given set of risks, and is trusted by the further inside layers. This further out layer often is just a https/tls accelerator and firewall. Each layer needs to record audit logs (usually not FHIR AuditLog), most of the time configured to only store failures. All of this is common stack building based on http REST orchestration. Each layer can scale independently because of that http REST common structure.
Mohammad Jafari (May 14 2019 at 15:34):
Thanks for this post @Grahame Grieve . Given that I have an experimental implementation of this out there (Pauldron-Hearth) I have some thoughts which I will share when I get a chance to write a blog post and address some of the details.
Rick Hawes (May 16 2019 at 18:34):
Thank you for beginning this discussion with your blog post. I work on the Centers for Medicare and Medicaid's Blue Button project, which internally has the Auth (AS) / Resource (RS) service separation that you mention. We are experimenting with expanding the types of authorization we allow to access our FHIR resources as well as bulk export. So this discussion is very relevant to us.
You mentioned auditability in your post. To me, auditability or accounting (the last A in AAA) has not been thought about enough in the systems that I've seen. It seems essential to building trust in our open standard systems. So I like the critique that decoupling authentication and resource service doesn't provide an "integrated audit trail in the base application." I want to fix this problem with this architecture. I'd be interested in what approaches the community is using to address this problem.
Grahame Grieve (May 16 2019 at 22:27):
I'm not aware of any common approaches. If you're using the token introspection approach, then the RS can get the user id from the AS as part of the token introspection, and should do it that way
Grahame Grieve (May 16 2019 at 22:27):
if your using a facade approach, then the authorization header passed to the inner server should include something that identifies the user
Grahame Grieve (May 16 2019 at 22:27):
but those are just my feelings. I can't point at anything
Mohammad Jafari (May 18 2019 at 23:49):
@Rick Hawes We (VHA) have previously demonstrated generating FHIR AuditEvents, either by the Authorization Proxy (aka Appliance as Grahame calls it), or the Authorization Service as a module inside the FHIR server. I will see if I can find the documents since this was a few years ago but I am also happy to chat if your team if working on this.
Our approach was in line with what @Grahame Grieve describes above, i.e. using the information from the introspection response to create the AuditEvent resource. However, audits usually require information that is beyond the standard OAuth Introspection response. For example, some information about the Client could be part of the Client's OAuth registration record and not part of the record for issuing the authorization token. Or, the reasoning behind the AS's decision to grant access to the client, e.g. policy or patient consent references. So, we found the standard OAuth Introspection response quite minimal and using extensions for recording additional information required for the AuditEvent inevitable.
John Moehrke (May 20 2019 at 13:22):
This is fundimentally why IHE-ATNA recommends that both sides of a transaction record their perspective on the AuditEvent. That is to say that the client side often knows a bit more about the context of the transaction that they can include in their AuditEvent. When doing audit log analysis one can look for paired entries, and use the combined knowledge. But one can also find non-paired entries and suspect that something improper is happening. The AuditEvent log is useful for many things.
John Moehrke (May 20 2019 at 13:24):
when orchistating many value-add intermediary, one would optimally get an AuditEvent from each layer. Thus for any one transaction at the lowest FHIR core server, one might see 1 or more related AuditEvent. Note that one can also see that an intermediary is adding value by summarizing many low-level FHIR core requests into one response given to the application.
Rick Hawes (May 20 2019 at 14:46):
Thanks for your responses @John Moehrke @Mohammad Jafari and @Grahame Grieve . It seems like AuditEvents is the key capability that I should shoot for. I appreciate the advice that OAuth token introspection is unlikely to provide enough context information to generate a full AuditEvent in a distributed system and that both sides need to record their information. This makes think of correlation ids, as in the x-correlation-id header in HTTP, might be something I want to add. John and Mohammad, what do you use these in your systems?
Last updated: Apr 12 2022 at 19:14 UTC
