I’m trying to use the Orthanc web viewer in my own website so that doctors can see the images given an ID. The problem is that I must protect the URL so no one can access the root system.
This can also be done at a higher level in some Web application (for instance in PHP), or in your reverse proxy. I will personally not provide any support about this topic, as this highly dependent on your workflow."
I guess I finally got it. Instead of creating this script, I configured the Authorization plugin. This way, I had to create an endpoint and put that endpoint on the orthanc.json file so every request was redirected to my endpoint and there I was able to choose if the request should or not pass.
@ Sébastien can you tell me if it secure just to check if the request has “osimis-viewer” or “orthanc-id” on its content?
Thanks!
A quarta-feira, 14 de outubro de 2020 à(s) 14:30:22 UTC+1, Clasus escreveu:
I experimented around with various methods for access controls for users. I did work with the Authorization Plug-in a little, but I think there are some limitations with that also since I do not think you can limit access in a granular way (i.e. only a particular referring physician, a particular patients by MRN, or a particular study).
If you are familiar with NGINX reverse proxies and the http_auth_request module that comes with that, that provides a mechanism without Lua Scripts or the Orthanc Auth Module.
There are many tutorials about how to use that on the web. It can get a little complicated, but if given a study uuid (e.g.), the initial request is like the following.
If you want granular control there is some checking to do regarding access to the study (i.e. patientid, referring physician), and you probably want to only have access to the osimis-viewer url and no other explorer or REST api call urls. Also, the subsequent requests for series and images and .js .css can be filtered via NGINX and a web app or the auth module.
It is a bit of a pain to set up, but using an NGINX server with Orthanc actually works pretty well.
are on the Orthanc Book. If you are interested in using NGINX I suggest that you read the link above and to a little research to see if that route would work for you.
If you just want to limit access to the viewer but are OK with allowing users access to the entire library of studies, I think you can use the Orthanc Auth Plug-in for that, although NGINX would allow you to do the same thing.
Firts of all, thank you Sebastien and ssc for your answers.
So, I have been working with the Authorization Plugin and for what I want it is okay. However, I would like to increase the security so I’m trying to use jwt but I have a problem: when accessing osimis-webviewer, the system does mora than one call to the Orthanc system. In the first request (the one I programed) I did put the token there but the subsequent ones doesn’t have the token so, they are automatically ignored by the plugin.
Does any one knows how can I solve this?
Thanks!
A segunda-feira, 19 de outubro de 2020 à(s) 15:02:50 UTC+1, ssc...@icloud.com escreveu:
Update: I solved my problem. There was a error on the URL that I was building and I defined on orthanc.json the folders/resources available for everyone
A sexta-feira, 23 de outubro de 2020 à(s) 16:05:46 UTC+1, Clasus escreveu:
So the setup is not that complicated. To make things work the way I have you must enable Authentication Plugin. For the people that don’t know what that plugin does, it redirects all requests to a certain endpoint that you specify. On that endpoint that you create, you can inspect in a basic way all the requests (see the Orthanc manual) and decide with your own rules, if you accept the request or reject it. This is usefull to limit the API methods that are available and also to block or not the access to the Osimis/Orthanc Viewer. As the system is (still?) not the most complete, you cannot know the original IP address that made the request which would be grate for setting other type of rules in our endpoint (for example, allow every request that is sent from an IP address). With this plugin you can also specify which directories/files the authorization plugin can ignore and allow it straight away which you must specify in order to make things work (I used the ones in the example on the manual).
Since this is still not that secure, I use JWT where I have put some info that is usefull for me such as the role (patient, medic, etc). This way, I can verify on the authorization endpoint if the request is valid (it must contain the token and it has to be valid) and allow it based on that info.
The problem I have is that the web interface doesn’t load correctly (some css is missing) maybe because some subsequent request is made without the token and is automatically ignored by the plugin (I cannot control that). However, for what I what that is not a big issue but would be grate to be able to use it correctly.
A sexta-feira, 23 de outubro de 2020 à(s) 17:46:29 UTC+1, s.jo...@gmail.com escreveu: