mcjustin
commented
3 months ago Paul: Filter the request, not the response... Note that jwt-proxy interprets patient identifier from the token depending on the launch mode (femr|epic). Short-term, put this in a new branch and use that in LTT. https://github.com/uwcirg/jwt-proxy/blob/main/jwt_proxy/api.py#L70
Longer term:
Configuration value to enable this mode: scope_filter
python module to determine if URL is good or bad.
Would be good if environments could declare that this module should be enabled.
Use case (Let's Talk Tech aka LTT): patients log on to a front-end only app (SHL creator, https://github.com/uwcirg/shl-ltt) that uses jwt-proxy. We want to prevent the patient from using that app to CRUD resources that are associated with other patients. The resources in this use case include only Patient and DocumentReference.
In LTT, dhair2 saves the KC user ID to the Patient resource as an
identifier, and then the SHL creator uses that identifier when querying for resources related to it:https://fhir-auth.inform.dev.cirg.uw.edu/fhir/Patient?identifier=3dfb8924-8e64-4ae0-b823-1baf66657000https://fhir-auth.inform.dev.cirg.uw.edu/fhir/DocumentReference?_count=1000&_sort=-date&subject.identifier=3dfb8924-8e64-4ae0-b823-1baf66657000... and when it POSTs to/DocumentReferencewith request body containing a conditional subject reference likePatient?identifier=[keycloak user id].jwt-proxy will need to read the Keycloak user ID from the JWT (in payload/data:
sub).Aside: the
SHL-viewerisn't a problem here, as it doesn't communicate with the FHIR server directly (instead, uses the https://github.com/uwcirg/shl-ltt-server).Per https://www.pivotaltracker.com/story/show/187355462