Stream: FHIR at Scale Taskforce (FAST): Security
Topic: JWT+PKI+mTLS to enable unregistered clients?
Joe Lamy (Sep 14 2021 at 03:14):
Today, multiple exchanges use SAML client assertions in combination with mTLS to authenticate the client system in SOAP web services as a prelude to the authorization decision. The use of PKI removes the need to exchange edge system certificates (analogous to registering specific clients with specific servers). Could FAST Security allow something similar, relying on a signed JWT and mTLS, perhaps for the client credentials flow?
Julie Maas (Sep 14 2021 at 14:42):
Hi Joe, we had mTLS scenarios at connectathons for some time a few years ago. There are a number of reasons the JWT-based approach was preferred. It allowed folks to use their FHIR servers with the least modification, i.e. the assertions are evaluated by the authorization server so that the FHIR server can continue to use less complex access tokens. It also moves the client signature from the handshake to the payload which facilitates working with TLS termination at gateways and load balancers. This also allows URI/path level certificates instead of domain level certificates, which are not as granular as some had preferred. Also re: the unregistered clients, I think this question was asked at the last connectathon: during Carequality stakeholder discussions, it was felt that the registration step could not be bypassed (as the existing FHIR systems expect a pre-registration). I'd also say that although it is a wash for one-off data requests, if a client makes millions of requests of the same server, registering once is more efficient than effectively repeating that every request.
Joe Lamy (Nov 10 2021 at 20:04):
Thanks, Julie. What you say makes sense. I'm thinking of the opposite motivator, which is systems that are already deployed using mTLS and SOAP that wish to add FHIR. In their case they already have paid whatever price you point out for dealing with mTLS, and could gain a benefit by not needing to register each client for OAuth (while I realize it's not a huge burden to do so). I just wondered if there was a clear downside for permitting this variant, should both sides agree.
Last updated: Apr 12 2022 at 19:14 UTC
