I am writing a plugin for Orthanc in C++. Its main goal is to handle authentication and authorization. I know there is an authorization plugin, but I don’t want to interface with keycloak but with our own auth server.
I have registered a IncomingHttpRequestFilter function and in this function I am calling an endpoint on our server using the OrthancPluginHttpClient function. The problem is that our server (at least in dev) has a self-signed certificate and the call fails. I tried setting HttpsVerifyPeers to false in the global configuration, but it didn’t solve the problem somehow. Is there something I can do ?
I also have a few more questions:
Is making a new plugin the way to go for this problem ? Or can I use already existing functionnalities to achieve this ?
Is Orthanc Explorer 2 supporting the token system of the legacy UI (as specified here ? That would be a life-changer as my users are token authentified and I want to restrict accesses to the API and I can’t really discriminate between calls from OE2 (allowed) and calls from the exterior (denied without authorization)
With further research into the doc and the code, I have partially answered my side questions (not the main one though).
The authorization plugin may look like the answer, but it doesn’t achieve the level of granularity and control we are looking for, so I guess the filter is the way to go.
OE2 is passing a token as a header only when keycloak is enabled. Do you think it could be a good idea to allow this functionnality when keycloak is not enabled ? I can create a PR for it.
I have also thought of another question :
Can I redirect a request while in the filter function ? I don’t have access to the response object, but I think I saw someone using RegisterRestCallback in this function to redirect unauthorized routes.
If you mean open OE2 with an url like http://localhost:8042/ui/app/?token=my-token and include that token as a header to all HTTP requests issued by OE2: Yes, that makes sense and feel free to make a PR for it.
I don’t think so, the filter should return 1 (authorized) or 0 (forbidden). Where have you seen that ?
I think that HttpsVerifyPeers only applies to the requests that are issued by the Orthanc-core. If, in your plugin, you create a new HttpClient, you need to disable verification on that particular HttpClient instance e.g:
Another alternative would be to use OrthancPluginHttpClient to ask the orthanc-core to perform the call with an HttpClient that would be created inside the orthanc-core.