Stream: Security and Privacy
Topic: Security model for FHIR API based on signed JSON Token
Ivano Tomainu (Nov 25 2019 at 08:56):
As anticipated in #implementers stream here is a proposal for discussion about the security model we have implemented.
SCENARIO
We have to publish a FHIR API to a trusted third party (e.g. a private clinic), we don’t want to know the registry of their users, we don’t want to manage singular permissions. The API is invoked from the server of the third party to our server, not directly form a client.
SECURITY CONSTRAINTS
• Communication between servers must be encrypted
• We must enable only some third parties to call the service
• We have to audit WHO used the service, at what time, for which patient…
SECURITY MODEL
The first two requisites are covered by using the TLS protocol, restricted by server IP, with a mutual certification; the certificate is nominal for each party and is released by our Certification Authority (the private key is held by the third party).
To perform the audit trail of the singular operation we ask the caller to assert what follows:
• Timestamp
• Requestor ID
• Operator ID
• Operator role
• Resource ID
All mentioned fields must be passed in the header of the REST call, inside a signed JSON token that must have this structure:
BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)
The last part of the token is the signature of header and payload, in accordance with JWS standard (Json Web Signature RFC7515).
IMPLEMENTATION
The JOSE header is structured as follows:
{"typ":"JWS","alg":"SHA256"}
Payload sample:
{"requestorId":"EXTP056","operatorId":"AS0562","operatorRole":"HOPERAT","timeStamp":1568807570957,"resourceId":"<fiscal-code>"}
Signature must be applied with the same certificate used for TLS, that has a public key for signature.
REFERENCE STANDARDS
To design this solution we tried to apply recommendations of the following documentation/standards:
FHIR Release 4: http://hl7.org/fhir/
Mobile security considerations: https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z.pdf
Security and Privacy module: http://hl7.org/fhir/R4/secpriv-module.html
JWS standard: https://tools.ietf.org/html/rfc7515
SUMMARY
What’s relevant in this security model is that the token is generated by the invoker of the service, not released by an IDP server, it works more like a SAML Assertion rather than a JWT. This simplifies the security level as we don’t have to manage OAuth and to keep the registry of the operators of external parties. Another advantage is that the token is “refreshed” at every call and carries updated attributes for audit trail.
John Moehrke (Nov 25 2019 at 15:36):
This seems rather similar to the IHE IUA profile of OAuth. In that model there is a well defined JWT set of attributes.
I am a fan of Mutual-Authenticated TLS, but it tends to have issues at the server interface. Especially when the server is using TLS accelerators that strip off the TLS.
https://healthcaresecprivacy.blogspot.com/2016/11/is-iua-oauth-useful-in-service-to.html
John Moehrke (Nov 25 2019 at 15:38):
IHE is currently updating the IUA profile due to some evolution of some draft IETF specifications. All are welcome to participate in that effort. I am sure that team would welcome your perspective. https://github.com/IHE/IT-Infrastructure/tree/master/IUA.b
Ivano Tomainu (Nov 26 2019 at 10:58):
Thanks for your answer John, I've looked at the mentioned solutions and they are indeed similar to our model. The token attributes mentioned in IUA Profile confirm that we are on the right path.
I was wondering: could the lack of a FHIR Resource to describe the token raise an issue?
Jens Villadsen (Nov 26 2019 at 12:52):
I have setup that resembles yours @Ivano Tomainu , bridging SAML over OAuth2 with JWTs. What part of the model do you think lacks a FHIR Resource modelling?
Ivano Tomainu (Nov 26 2019 at 13:01):
The JSON of the payload inside the token.
Consider that I work in a context similar to SAML Identitiy Federation, I'm in charge to release specification for the use of the service.
Jens Villadsen (Nov 26 2019 at 13:14):
your JWT adheres to the JWT spec, right?
Jens Villadsen (Nov 26 2019 at 13:15):
We've done the following: https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/291176482/Tokens+roles+and+RBAC+ABAC#TheAccessToken
Ivano Tomainu (Nov 26 2019 at 13:28):
Thanks, very useful.
I agree that's more important to adhere to this specification: https://www.iana.org/assignments/jwt/jwt.xhtml
rather than any other for the JSON Payload.
Luis Maas (Dec 02 2019 at 17:14):
Hi @Ivano Tomainu,
I would also point you to the UDAP profiles for including this type of information in JWTs, specifically: UDAP Client Authorization Grants using JSON Web Tokens. This particular profile includes an extensions parameter specifically intended to carry the types of metadata you are describing.
In your specialized situation, the Authorization JWT defined in that profile could be used as a standalone Authorization header payload.
Additionally, since your FHIR server is presumably validating the JWT presented by the client, I would also note that the UDAP profiles are designed to link X.509 certificate frameworks to the trust model. This means that the JWT submitted by the client can also be used for authentication, in which case you may be able to simplify your workflow by removing the TLS client-side authentication altogether since client certificate validation is also part of the UDAP flow.
These profiles have been tested at several HL7 FHIR connectathons. You can also find additional information about UDAP on the FHIR Security page and at http://www.udap.org.
Ivano Tomainu (Dec 13 2019 at 10:39):
Thanks @Luis Maas , is very interesting the fact that they talk of a JSON Assertion, it's exactly the concept we're replicating from SAML.
A part from that the server architecture is a bit different, we don't use Oauth Server.
Last updated: Apr 12 2022 at 19:14 UTC
