We need to handle basic authorization to access resources, for both dicom-web and regular API/viewer.
The criteria si quite simple: if the patient (based on PatientId) is reachable, all its relative resources are reachable too.
Everything works perfectly fine using the RegisterIncomingHttpRequestFilter hook.
Everything but QIDO-RS filtering.
Typically when requesting /dicom-web/studies, we have to restrict to the studies of the accessible patients.
Obviously the RegisterIncomingHttpRequestFilter is not intented to filter that since it only allow/disallow access to a specifically requested resource.
Is there a way to achieve that?
Thanks!
You probably already saw this:
https://book.orthanc-server.com/faq/authentication.html
Osimis had/has an authentication plug-in that is deprecated. You might want to consider using a reverse proxy setup if you need more granular control of access to resources.
Thank you for your answer Stephen. Yes, I saw the doc (and the Python plugin documentation). Actually, we’re trying to create a python script to replace the old auth deprecated plugin.
Actually, our issue isn’t an authentication issue but more a permission one.
Auth is fine, but when fetching non-specific results we’d need to filter them to only return those accessible to the requesting physician.
We reversed the legacy auth plugin, it handles specific dicom-web accesses : https://hg.orthanc-server.com/orthanc-authorization/file/default/Plugin/DefaultAuthorizationParser.cpp#l42 but does not seem to cover /studies/ filtering either.
Hi Maxime,
I would suggest you to override the qido-rs route in a python plugin:
- collect all results by calling the default qido-rs route (or even more filtering directly based on e.g PatientID prefix or whatever)
- and then, filter out the results your user is not allowed to access
HTH,
Alain.
Hi Alain,
Thank you for your answer and tips, that’s definitely the best way to achieve our goal.
We’ve played a bit with RegisterRestCallback to override the /dicom-web/studies endpoint.
Ideally we’d like to avoid putting too much logic there by simply wrapping the dicom-web plugin endpoint and defining the PatientId (or filtering it if already passed).
It works great until we have to call the overridden endpoint which is… unreachable or did we miss a thing?
Regards,
Hi Maxime,
What problem do you have exactly when trying to call the overridden endpoint ? Could you provide sample codes ?
Are you aware of the 2 overloads to call the “core” endpoint or the one overridden by the plugins:
OrthancPluginRestApiPost(
OrthancPluginRestApiPostAfterPlugins(
https://sdk.orthanc-server.com/group__Orthanc.html#ga05206ca54960536a65caee32118c42f5
Best regards,
Alain.