Stream: Security and Privacy
Topic: Cross organizational FHIR data access
Yaroslav Hradowy (Jun 08 2018 at 19:58):
We are building a solution based on FHIR server hosted in our network and allow external EHR systems (and perhaps external SPA applications) to access this FHIR endpoint. This interaction is covered in the fifth auth use case of the famous Argonaut project. And here there is draft of the solution (Cross-Organization Data Access Profile): https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/cross-organizational-auth. Is this specification will be included in the SMART on FHIR, or there are others proposals that are getting support of FHIR community? Maybe somebody already implemented such interactions.
Lloyd McKenzie (Jun 08 2018 at 21:58):
@Josh Mandel ?
Michele Mottini (Jun 08 2018 at 22:20):
To the best of my knowledge none implemented or is implementing it
Michele Mottini (Jun 08 2018 at 22:20):
More in general EHR vendors are focusing on providing FHIR end point to publish the data they hold, not to use FHIR to get data from other systems
Michele Mottini (Jun 08 2018 at 22:22):
For an external SPA application the standard SMART stand-alone launch would be enough
Michele Mottini (Jun 08 2018 at 22:23):
(http://docs.smarthealthit.org/authorization/)
John Moehrke (Jun 11 2018 at 13:09):
Wouldn't the bulk-data group be working on this? I would very much like to see a preference presented. In your specific solution, what are the partners looking to use? I think moving from where we are today to some community consensus preference, will require stakeholders experimenting. Inventing an academic solution will likely not be optimal. Optimal often is influenced by tools and technology available, not just academic theory. OAuth as outlined might work, but might also be rather chatty with little benefit. Use of Certificate backed authentication might be less chatty, but brings in server-side issues. see https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html
Yaroslav Hradowy (Jun 11 2018 at 18:23):
Wouldn't the bulk-data group be working on this? I would very much like to see a preference presented. In your specific solution, what are the partners looking to use? I think moving from where we are today to some community consensus preference, will require stakeholders experimenting. Inventing an academic solution will likely not be optimal. Optimal often is influenced by tools and technology available, not just academic theory. OAuth as outlined might work, but might also be rather chatty with little benefit. Use of Certificate backed authentication might be less chatty, but brings in server-side issues. see https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html
Hi John. Unfortunately we do not have a partner organization engaged with our project. We just looking for what is available as best practice or adopted approach by FHIR community, so we go with something that will require minimum adjustment in future, as well as from partner's perspective - they should not write a separate security implementation for each FHIR service provider. We'll be working with hundreds of partner applications in future.
I gained that the Cross-Organizational use case is not yet ready for prime time. So we'll have to use different approach. In your article you argue that mutually-authenticated TLS is sufficient for this kind of interactions, and OAuth2 is not needed. How then we should implement authorization part? At least we should receive end-user information for auditing purposes (as described in second JWT token in Cross-Organizational use case).
John Moehrke (Jun 11 2018 at 18:38):
I am not going to say that argonaut spec is not yet ready... The use of mutual-auth-TLS is logical... but has problems with firewalls. If you can manage that, then it likely is the best approach. The client in this case is identified by the client certificate. That identity in the client cert can be recorded in the audit log. This is very much what is done in many of the predecessor B2B communications like HL7 v2, v3, DICOM, and other. The firewall problem, which I do explain in the article is that often the TLS is terminated at the cloud edge, and therefore the backend doesn't have knowledge of the client. The backend does know that a legitimate client was authenticated, just not which. This can be handled, as I explain, through some in-the-cloud magic. Neither define how you determine what access is authorized, that must still be logic. Difference is that with OAuth you can put some of this logic into the AS, but you must still do the access control yourself. Supporting BOTH solutions might be a good choice for you.
Grahame Grieve (Jun 11 2018 at 23:02):
both of you should read the SMART backend services spec so that your dsicussion is illuminated by it
Yaroslav Hradowy (Jun 12 2018 at 18:00):
Grahame, it seems that SMART backend services spec ( http://docs.smarthealthit.org/authorization/backend-services) is more for data exchange between applications rather than interactive use of data from external FHIR-enabled application. This one uses the same jwt-bearer token as cross-organizational DAP but only for authentication. Authorization is through grant type Client Credential in first case, and the jwt-bearer in other. Client Credential type as opposite to jwt-bearer does not provide means to pass end-user information necessary for auditing of incoming requests.
Yaroslav Hradowy (Jun 12 2018 at 18:58):
Thanks, John, for clarification
Grahame Grieve (Jun 12 2018 at 22:57):
so I think that when the client system that is using backend services to connect is acting on behalf of a user, it should attach an openid token for the user to the request so that this auditing can happen, and this should be a standard part of the back-end services profile
John Moehrke (Jun 13 2018 at 12:55):
Yes, but isn't the scope of the backend services spec that there is no interactive user? If there was an interactive user then it would be possible to do normal SMART... I am not saying that sometimes a backend service does things onbehalf of a user (user triggered a workflow, workflow triggered a communication, but too far away from the interactive session t obtain an OpenId token)
John Moehrke (Jun 13 2018 at 12:58):
This can't be satisfied by an OAuth token, but would still be useful to the responding system for audit purposes... This is classically how the SAML token in XDS/XCA environments is used. Where the SAML token is an indication of the user, but is not usually verifiably proven. In these environments this is simply the result of a huge-federation that has no method of verifying SAML signatures by all IDPs.
John Moehrke (Jun 13 2018 at 12:59):
Are you suggesting that a JWT be created of a non-verifiable type, just so that it can carry user / context attributes? Would tooling allow this?
Grahame Grieve (Jun 13 2018 at 13:07):
isn't the scope of the backend services spec that there is no interactive user
Grahame Grieve (Jun 13 2018 at 13:08):
not at all. It's saying, the trust is established between the systems directly.
Grahame Grieve (Jun 13 2018 at 13:08):
the systems may be acting on behalf of a user, and trusting each other's claims in this regard. This is an extremely common approach in healthcare today
Grahame Grieve (Jun 13 2018 at 13:09):
I didn't say an OAuth token, I said an openID token
Grahame Grieve (Jun 13 2018 at 13:09):
of course, sometimes a system won't be able to connect things up. But I think that we should encourage standardising on an OpenID token in this case when the system can connect things
Last updated: Apr 12 2022 at 19:14 UTC
