Stream: ibm
Topic: oAuth
Mahesh Dabi (Aug 06 2021 at 06:43):
Scenario 1: patient/Patient.read
It is observed that when we send scopes "patient/Medication.read patient/AllergyIntolerance.read patient/CarePlan.read patient/CareTeam.read patient/Condition.read patient/Device.read patient/DiagnosticReport.read patient/DocumentReference.read patient/Encounter.read patient/Goal.read patient/Immunization.read patient/Location.read patient/MedicationRequest.read patient/Observation.read patient/Organization.read patient/Practitioner.read patient/Procedure.read patient/Provenance.read" in the token, to read Patientdetails with URL "http://3.84.221.213:9443/fhir-server/api/v4/Patient/17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be"
it denies access (as expected) because we have not given "patient/Patient.read" in the scope list in the token.
Following is a snapshot of the detailed trace
[8/6/21, 5:52:24:261 UTC] 0000002b AuthzPolicyEn 1 read permission for 'Patient/17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be' is not granted by any of the provided scopes: [patient/Medication.read, patient/AllergyIntolerance.read, patient/CarePlan.read, patient/CareTeam.read, patient/Condition.read, patient/Device.read, patient/DiagnosticReport.read, patient/DocumentReference.read, patient/Encounter.read, patient/Goal.read, patient/Immunization.read, patient/Location.read, patient/MedicationRequest.read, patient/Observation.read, patient/Organization.read, patient/Practitioner.read, patient/Procedure.read, patient/Provenance.read] with context id(s): [17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be]
[8/6/21, 5:52:24:262 UTC] 0000002b FHIRUserTrans 1 Marking transaction for rollback.
[8/6/21, 5:52:24:262 UTC] 0000002b FHIRUserTrans 1 Rolling back transaction on current thread...
[8/6/21, 5:52:24:264 UTC] 0000002b CacheTransact I Transaction failed - afterCompletion(status = 4)
[8/6/21, 5:52:24:264 UTC] 0000002b FHIRPersisten 1 Transaction rolled back - clearing local maps
[8/6/21, 5:52:24:266 UTC] 0000002b FHIRResource 1 Requested interaction is not permitted by any of the passed scopes.
Scenario 2: patient/AllergyIntolerance.read
When we send scopes "patient/Medication.read patient/CarePlan.read patient/CareTeam.read patient/Condition.read patient/Device.read patient/DiagnosticReport.read patient/DocumentReference.read patient/Encounter.read patient/Goal.read patient/Immunization.read patient/Location.read patient/MedicationRequest.read patient/Observation.read patient/Organization.read patient/Practitioner.read patient/Procedure.read patient/Provenance.read patient/Patient.read" , with no patient/AllergyIntolerance.read in it, it still allows access to Allergy of the patient (http://3.84.221.213:9443/fhir-server/api/v4/AllergyIntolerance?patient=17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be) and gives 200 OK. It is expected here, that it should deny access to this resource.
In the trace, we could not locate any log with AuthzPolicyEn 1, the way it was present when we ran scenario 1.
Even when we send no scopes in the token, the FHIR server still gives access to allergyIntolerance.
Are we missing anything? Please help.
Lee Surprenant (Aug 09 2021 at 13:59):
Hi Mahesh, do you actually get the allergyIntolerance back or do you get just an empty page of results?
Lee Surprenant (Aug 09 2021 at 14:10):
What the fhir-smart interceptor does is it converts the searches into Patient Compartment searches.
Then, mostly to deal with _include and _revinclude search parameters, it also confirms that the user has access to all the resources it is about to return. So, if AllergyIntolerance search cannot find any AllergyIntolerance for the "in-context" patient then I think it is expected that it will return en empty page.
With that said, I agree that it would be better to reject the search up-front. This can be done via either a gateway or within the FHIR Server, but the fhir-smart interceptor does not currently do that. Care to open an issue for it?
Mahesh Dabi (Aug 11 2021 at 12:31):
Thank you for your explanation of our previous questions. After we uploaded all resource-type data to a patient, the FHIR server started to honor scopes as expected. That means it will honor scopes only when there is patient data for those scopes.
While we were testing with the Inferno tool, now we are getting an error "UnsupportedOperationException: SMART scopes with context type 'user' are not yet supported.".
URL called:
http://54.88.8.62:9443/fhir-server/api/v4/Practitioner/17b350debf6-c44c90a7-7703-4bd9-bd57-6df97a2c0b9f
Token sent:
{
"iss": "https://identityserverforfhir.azurewebsites.net",
"nbf": 1628683595,
"iat": 1628683595,
"exp": 1628687195,
"aud": "http://54.88.8.62:9443/fhir-server/api/v4",
"scope": "launch openid fhirUser user/Medication.read user/AllergyIntolerance.read user/CarePlan.read user/CareTeam.read user/Condition.read user/Device.read user/DiagnosticReport.read user/DocumentReference.read user/Encounter.read user/Goal.read user/Immunization.read user/Location.read user/MedicationRequest.read user/Observation.read user/Organization.read user/Patient.read user/Practitioner.read user/Procedure.read user/Provenance.read offline_access",
"group": [
"FHIRUsers",
"FHIRAdmins"
],
"amr": [
"pwd"
],
"client_id": "Inferno",
"sub": "fhiruser",
"auth_time": 1628679442,
"idp": "local",
"sid": "C98717AE4B6939B04B9D68763BBE60D0",
"patient": "17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be",
"patient_id": "17ab437f80b-f1907e67-e141-467c-b3d9-c3f8ebd867be",
"upn": "fhiruser",
"need_patient_banner": "false",
"smart_style_url": "https://identityserverforfhir.azurewebsites.net/SmartOnFHIR/v1.json",
"jti": "8C0419C23EBBC63990064C53821C14F4"
}
Response received:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "fatal",
"code": "exception",
"details": {
"text": "UnsupportedOperationException: SMART scopes with context type 'user' are not yet supported."
}
}
]
}
Could you please help us with that?
Lee Surprenant (Aug 11 2021 at 13:11):
That means it will honor scopes only when there is patient data for those scopes.
yep. however, I think you've convinced me that we should be more restrictive (even with no data being returned) and so I opened https://github.com/IBM/FHIR/issues/2669 and that change is now expected for IBM FHIR Server 4.9.0
Mahesh Dabi (Aug 11 2021 at 13:28):
Yes absolutely. As I see the last comment on the issue in github it says "use of user/ permissions is still not implemented for some cases" For now we are looking for read permission. Any idea when that can be available approximately? Is there any custom fix we can do till release for short- term. I mean if we can get Jar with this change (final release can take its own time as per schedule and it is ok)
Thanks a lot and appreciate your help.
Lee Surprenant (Aug 11 2021 at 16:32):
We merged https://github.com/IBM/FHIR/pull/2675 this morning and that is now also expected for 4.9.0
Lee Surprenant (Aug 11 2021 at 16:32):
you can checkout and build from main today
Lee Surprenant (Aug 11 2021 at 16:35):
In the past I left supporting user/ scopes as a TODO because, for most cases, it should really be tied to a more granular permissions model. However, thats extremely challenging to do in a generic fhir server like ours, so this pull request just goes with the proposal that I read on Zulip a while back: https://chat.fhir.org/#narrow/stream/179170-smart/topic/Authorization.20for.20transactions/near/213346765
Lee Surprenant (Aug 11 2021 at 16:37):
If you do check out from main, let us know how it goes ASAP because we are very close to releasing 4.9.0. We're testing it on a few projects ourselves, but it would be great to have some independent verification of these late-breaking fhir-smart changes.
Mahesh Dabi (Aug 12 2021 at 09:27):
Hi Lee
Where can I get fhir-smart-4.9.0.jar? I can test that with latest release of IBM FHIR Server 4.9.0. Also what will be dependencies for this jar or it will work with old version of dependencies?
Right now we are having following dependencies in usrlib folder
Thanks
Mahesh
Lee Surprenant (Aug 12 2021 at 13:44):
We tagged 4.9.0 last night and the artifacts have been promoted to Maven Central. So you can get from https://repo1.maven.org/maven2/com/ibm/fhir/fhir-smart/4.9.0/ or you can use Maven to get it (and its transitive dependencies). I don't think there were any dependency version updates for fhir-smart in this release.
Mahesh Dabi (Aug 12 2021 at 13:59):
Great. I saw the code change in github. Please see attached screenshot of inferno.
During bulk export, we would need to honor system scopes. Also, has signature algorithm something to do with FHIR server?
Lee Surprenant (Aug 12 2021 at 14:14):
Cool, I havn't done too much with that. Please open an issue for it at github.com/ibm/fhir with what you're seeing and what you'd like to see.
Lee Surprenant (Aug 12 2021 at 17:45):
has signature algorithm something to do with FHIR server?
From the FHIR server side, I think its just about being able to validate the tokens we get passed. We opened an issue requesting specific support for ES384/RS384 in OpenLiberty a while back and the ticket is still open...but I havn't tried it in a while and there's always a chance that it could be made to work despite the issue being open still. If you decide to give it a go, let us know how it goes.
Mahesh Dabi (Aug 17 2021 at 10:56):
Hi Lee
We tested latest version of smart and scoping is working as expected. really appreciate your help for addressing this in your busy release schedule.
I will test more and get you some feedback.
Thanks
Mahesh
Mahesh Dabi (Oct 04 2021 at 10:29):
We successfully installed the latest IBM FHIR 4.9.2 and worked fine with basic authentication.
Now when we configured it to use the SMART feature it is giving us the below exception. while running a GET on https://fhir.secureit.co.in:9443/fhir-server/api/v4/Patient
We have the following jars under userlib.
fhir-smart-4.9.2.jar
java-jwt-3.13.0.jar
Do you think we are missing more dependencies?
Exception:
[INFO ] Received request: tenantId:[default] dsId:[default] user:[fhiruser] method:[GET] uri:[https://fhir.secureit.co.in:9443/fhir-server/api/v4/Patient]
[INFO ] Transaction failed - afterCompletion(status = 4)
[WARNING ] Application {http://resources.server.fhir.ibm.com/}Create has thrown exception, unwinding now
com/fasterxml/jackson/databind/JsonDeserializer
[WARNING ] Exception in handleFault on interceptor org.apache.cxf.jaxrs.interceptor.JAXRSDefaultFaultOutInterceptor@341d5864
com/fasterxml/jackson/databind/JsonDeserializer
[ERROR ] An unexpected error occurred during error handling. No further error processing will occur.
com/fasterxml/jackson/databind/JsonDeserializer
[ERROR ] SRVE0777E: Exception thrown by application class 'org.apache.cxf.service.invoker.AbstractInvoker.createFault:167'
org.apache.cxf.interceptor.Fault: com/fasterxml/jackson/databind/JsonDeserializer
at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:167)
at [internal classes]
at com.ibm.fhir.server.filter.rest.FHIRRestServletFilter.doFilter(FHIRRestServletFilter.java:155)
at javax.servlet.http.HttpFilter.doFilter(HttpFilter.java:127)
at [internal classes]
Caused by: java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/JsonDeserializer
at com.auth0.jwt.JWTDecoder.<init>(JWTDecoder.java:32)
at com.auth0.jwt.JWT.decode(JWT.java:45)
at com.ibm.fhir.smart.AuthzPolicyEnforcementPersistenceInterceptor.beforeSearch(AuthzPolicyEnforcementPersistenceInterceptor.java:113)
at com.ibm.fhir.persistence.interceptor.impl.FHIRPersistenceInterceptorMgr.fireBeforeSearchEvent(FHIRPersistenceInterceptorMgr.java:175)
at com.ibm.fhir.server.util.FHIRRestHelper.doSearch(FHIRRestHelper.java:1076)
at com.ibm.fhir.server.util.FHIRRestHelper.doSearch(FHIRRestHelper.java:1017)
at com.ibm.fhir.server.resources.Search.doSearch(Search.java:74)
at com.ibm.fhir.server.resources.Search.searchGet(Search.java:51)
at com.ibm.fhir.server.resources.Search$Proxy$_$$_WeldClientProxy.searchGet(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.ibm.ws.jaxrs20.cdi.component.JaxRsFactoryImplicitBeanCDICustomizer.serviceInvoke(JaxRsFactoryImplicitBeanCDICustomizer.java:342)
... 4 more
[INFO ] Error while setting request context or processing request
com/fasterxml/jackson/databind/JsonDeserializer
[INFO ] Completed request[0.04 secs]: tenantId:[default] dsId:[default] user:[fhiruser] method:[GET] uri:[https://fhir.secureit.co.in:9443/fhir-server/api/v4/Patient] status:[400]
Mahesh Dabi (Oct 04 2021 at 11:44):
Error on this line
Lee Surprenant (Oct 05 2021 at 11:40):
Hi Mahesh, sorry to hear that. The concerning line is this one:
Caused by: java.lang.NoClassDefFoundError: com/fasterxml/jackson/databind/JsonDeserializer
Which version of the jackson jars do you have in userlib (alongside fhir-smart) ?
Mahesh Dabi (Oct 06 2021 at 15:02):
We have the following jars under userlib.
fhir-smart-4.9.2.jar
java-jwt-3.13.0.jar
For the previous versions of IBM FHIR we had this same set of jars and it worked fine.
Lee Surprenant (Oct 06 2021 at 15:29):
OK, I additionally have these ones:
- commons-codec-1.14.jar
- jackson-annotations-2.11.0.jar
- jackson-core-2.11.0.jar
- jackson-databind-2.11.0.jar
You may have just gotten lucky that those other ones were in our webapp. Like maybe the Cassandra stuff that was in there was pulling those in, but for 4.9.2 we slimmed it down a bit (via https://github.com/IBM/FHIR/pull/2757).
Lee Surprenant (Oct 06 2021 at 15:30):
With that said, this conversation has motivated me to see about removing our java-jwt dependency (the thing that pulls in those transitive dependencies). So I opened https://github.com/IBM/FHIR/pull/2833 as a draft PR...let me know what you think.
Lee Surprenant (Oct 06 2021 at 15:30):
Unless we do something like that, you'll need to be sure you're packaging all the fhir-smart dependencies in userlib
Last updated: Apr 12 2022 at 19:14 UTC
