How do I get rid of the "Insecure setup..." message in orthanc-server's web interface?

[Martin Biermann]

We recently launched our own orthanc-server in our university network behind the university firewall: https://nukit.uib.no

The orthanc server runs in a docker container (using jodogne/orthanc-plugins) behind apache2 httpd as a reverse proxy under CentOS.

Security is provided by the reverse proxy: https/SSL transport layer security, user authentication against the university’s central user administration using ldap, and authorization using an apache group file.

In the orthanc.json we set
"AuthenticationEnabled" : false
since authentication is done via apache httpd.

We also found out that we have to set

"RemoteAccessAllowed" : true,

otherwise the orthanc-server will not allow logins.

When we use a Fiji/PET-CT viewer with the Orthanc Tools plugin, everything is fine.

When a user logs on on the server via a web browser, she will see the ominous warning:

“Insecure setup

Your Orthanc server is accepting remote connections, but is using the default username and password, or has user authentication explicitly turned off. Please carefully read your logs and review your configuration, especially options RemoteAccessAllowed, AuthenticationEnabled, and RegisteredUsers.”

How can we get rid of this warning? Our configuration IS as safe as it gets, only that safety is provided outside the orthanc-server container.

Unless there is some workaround that I have overlooked (I ran multiple searches with the keyword "insecure") I suggest having a separate parameter i orthanc.json as a new feature:
”InsecureSetupWarning”: true (default) 

Setting the parameter to false would override the warning in case of configurations like ours.

Kind regards

Martin

[Benoît Crickboom]

Hi Martin,

Thanks for your feedback and the description of your setup!

Sebastien introduced that warning message given a lot of Orthanc users are not IT specialist and so, it appeared that several Orthanc servers around the world were insecurely configured and reachable from anywhere.

Beside these badly configured Orthanc, there are people like you with knowledge and who manage safety outside of Orthanc. We had the same idea as you: a parameter allowing to hide the warning message. But we decided not to go in that way to avoid the introduction of an easy way to bypass warning. Indeed, that would have been the same as no warning (unfortunately, people usually don't care about security).

I let Sebastien confirm that explanation and maybe propose a workaround for your case.

HTH,

[Sébastien Jodogne]

Dear Martin,

As explained by Benoît, we have decided to add this warning message in Orthanc 1.5.8 in order to clearly warn about the fact that clinical information might be put on Internet without protection by users who are not IT specialists.

The solution to your issue is simply to add a user that will be used by your reverse proxy. Here is a sample Orthanc configuration:

{

  "RemoteAccessAllowed": true,

  "AuthenticationEnabled" : true,

  "RegisteredUsers" : {

    "admin" : "XXXX"

  }

}

In the configuration of the Apache reverse proxy, you would then provide the credentials of user "admin" thanks to the "RequestHeader set Authorization" command:

https://stackoverflow.com/a/571260/881731

Here is the equivalent procedure for nginx:

http://shairosenfeld.blogspot.com/2011/03/authorization-header-in-nginx-for.html

HTH,

Sébastien-

[Benjamin Golinvaux]

Can you maybe configure your reverse proxy to always include an http authencation header, so that the warning disappears ?

For instance, adding the orthanc:orthanc user/password pair, and providing the base64 encoded pair as a fixed header.

I am using nginx, but I assume Apache allows adding fixed headers.

That would slightly hinder access from inside by requiring login, but I assume everybody can use the httpd proxy instead ?

HTH. Let us know how it goes!

[Martin Biermann]

Dear Sébastien,

I understand. Having an override parameter as suggested by me in my post would be too easy. I share your concerns.

Adding authentication to the reverse proxy is a nice tweak. We will try it out.

We did not want authentication in the orthanc.json since we will have up to 300 active users which will change twice a year. Integrating apache httpd with the university's LDAP server was the most robust solution for us, put the initial price to pay was the nag massage in the web interface.

We will follow your suggestion and report the outcome.

Kind regards

Martin

[Sébastien Jodogne]

Hello,

Just to be clearer: You just have to create *one* user in Orthanc.

This single user must only be used form communications between Apache and Orthanc. You don't have to create 300 user accounts.

Once Apache can talk to Orthanc using this single user, your Apache server can perfectly handle the authentication of the 300 users through LDAP.

HTH,

Sébastien-

[Martin Biermann]

Dear Sébastien,

I understood that you only need 1 user i orhanc.

Since we are dealing with several hundred users here it is very important that authentication is via apache2 httpd, which is integrated with the university's user administration via ldap.

I implemented your suggestion today - it worked right out of the box.

Thanks a lot!

[John Roberts]

I followed this discussion for a while and avoided upgrading for the same reason.  We also have a reverse-proxy setup using our Apache's interface with the university single-sign-on service to manage authentication.

One issue I have with having "one user" on the back end is the allocation of user rights.  Under the old system, I used the Lua IncomingHTTPRequestFilter method to control some of the user rights based on the incoming x-remote-user in the HTTP headers.  For example, only those previously identified as admin could execute LUA scripts.  At the Apache level, I also managed some rights based on the incoming user's name and AllowMethods.

I would have to think about whether this is still possible and whether I'd need to move all of the user access control up a level and manage it on the Apache side since IncomingHTTPRequestFilter might only ever see "one user".

John.

[Sébastien Jodogne]

You can perfectly combine the "one user" approach with the validation of HTTP headers inside "IncomingHTTPRequestFilter()" of Lua: The reverse-proxy can be configured to set HTTP headers depending on the access rights of the user.

Python plugins could also be used here if you need more complex interactions with Web services (for instance LDAP):

https://book.orthanc-server.com/plugins/python.html#forbid-or-allow-access-to-rest-resources-authorization

Sébastien-

[John Roberts]

Ah, I think I see your point.  I could create multiple users on the Orthanc side with varying levels of permissions and then control on the Apache side what user is called based on the user authenticated by my single sign on service.