Stream: Security and Privacy
Topic: backend service secure communication
John Moehrke (Apr 03 2018 at 13:52):
Where we have SMART-on-FHIR to support apps speaking to a FHIR server, we do not have a clear security model for when organizations have backend communications. Presume the authorization to access is legitimate, and at the organization level. Such a case might be a EHR communicating with a Health Information Exchange under pre-negotiated trust relationship (for example a DURSA, and purposeOfUse of Treatment). Clearly HTTPS can be used to protect the communications channel confidentiality, integrity, and server authentication. But how does the server know that the requesting organization is legitimate and authenticated?
John Moehrke (Apr 03 2018 at 13:52):
Please provide links or description of possible models:
John Moehrke (Apr 03 2018 at 13:57):
Mutual-Authenticated-TLS -- This is commonly used in SOAP, and can be used in REST; however common REST api toolkits tend to terminate the TLS at the edge, thus the backend server service has no identity to associate with the request. There are configurations, as documented in F5 manual, where the client certificate ID can be stuffed into the http headers in the infrastructure. This clunky and has risks. The benefit is that certificate management is relatively easy for these kind of situations, and revocation mechanism is sufficient. https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html
John Moehrke (Apr 03 2018 at 13:59):
signed JWT Bearer token for the client service, HTTPS for everything else. This would operate on the server side just like any SMART-on-FHIR. Bootstrapping the client is hard. There are profiles in the W3C/OASIS that show how to do this. https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html
Grahame Grieve (Apr 03 2018 at 18:12):
so argonaut is testing Smart back end services this year
Grahame Grieve (Apr 03 2018 at 18:13):
http://docs.smarthealthit.org/authorization/backend-services/
Grahame Grieve (Apr 03 2018 at 18:13):
several of us have iumplementations of that
Nick Hatt (Apr 03 2018 at 22:43):
Interesting blog post on mutual TLS. Interestingly, AWS API gateway does not support client certificates for authenticating HTTP inbound, but ONLY supports client certificates as a way to authenticate to a backend service. Wild.
Anyways, the SMART backend services proposal follows what others such as Google have done for their APIs (see gRPC for example https://grpc.io/docs/guides/auth.html).
The biggest flaw in JWT is the flexibility of the alg property. Check out the NVD database and most of them boil down to people doing the validation wrong. https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=JWT&search_type=all
SMART is doing a good thing by insisting on asymmetric keys (rs256) vs symmetric keys (hs256). If you visit jwt.io the default is always going to be hs256 because it's easier to illustrate. It's easier to protect the secret with rs256, and by standardizing on one method, servers won't need to build two separate secret infrastructures - one for hs256 secrets and one for rs256 public keys.
Grahame Grieve (Apr 03 2018 at 22:46):
https://chat.fhir.org/#narrow/stream/cds-hooks-github/subject/docs.20.2F.20Issue.20.23187.20JWT.20alg.20should.20be.20standardized - relevant to algorithm
John Moehrke (Apr 04 2018 at 13:17):
The IETF agrees on the use of asymmetric keys. We should all be following IETF RFC6819 - OAuth 2.0 Security. See 5.1.4.1.5. Use of Asymmetric Cryptography... We should not be re-learning and re-inventing these best-practices that the larger community provide to us freely and openly. https://tools.ietf.org/html/rfc6819
John Moehrke (Apr 18 2018 at 15:12):
Note there is a track at the upcoming FHIR Connectathon that has a proposal for doing backend services security. Please review and comment to help drive us toward one or more solutions http://wiki.hl7.org/index.php?title=201805_Direct/Certificates_Track
Last updated: Apr 12 2022 at 19:14 UTC
