OH3 with NGINX Reverse Proxy and Authentication

Setup, Configuration and Use Runtime
20

as far as I checked:

OH2 with nginx with Basic Auth - when I open Paper UI or Basic UI I needed to enter login and password same as in /etc/nginx/.htpasswd

on same nginx conf but on OH3 - when I open Openhab Main UI or Basic UI I needed to enter login and password set for administrator from Main UI

now I added SSL to nginx and on OH3 - when I open Main UI or Basic UI I enter login and pass from .htpasswd and also in Main UI addidtional login and pass for administrator.

here is my new nginx config:

#################################
# openHABian NGINX Confiuration #
#################################

## Reverse Proxy to openHAB
server {
        listen                          80;
        server_name                     xxxxxxxx;
        return 301                      https://$server_name$request_uri;
}

server {
        listen                          443 ssl;
        server_name                     xxxxxxxx;
        ssl_certificate                 /etc/ssl/openhab.crt;
        ssl_certificate_key             /etc/ssl/openhab.key;
        add_header Set-Cookie X-OPENHAB-AUTH-HEADER=1;
    location / {
        proxy_pass                              http://localhost:8080;
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto      $scheme;
        proxy_set_header Upgrade                $http_upgrade;
        proxy_set_header Authorization "";
        satisfy                                 any;
        allow                                   192.168.0.0/24;
        allow                                   127.0.0.1;
        deny                                    all;
        auth_basic                              "Username and Password Required";
        auth_basic_user_file                    /etc/nginx/.htpasswd;
    }
        location /grafana/ {
                proxy_pass                            http://localhost:3000/;
                proxy_set_header Host                 $http_host;
                proxy_set_header X-Real-IP            $remote_addr;
                proxy_set_header X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto    "https";
                auth_basic                            "Unauthorised access prohibited";
                auth_basic_user_file                  /etc/nginx/.htpasswd;
        }

    location /frontail/ {
        proxy_pass                              http://localhost:9001;
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto      $scheme;
        proxy_set_header Connection             "upgrade";
        proxy_set_header Upgrade                $http_upgrade;
    }

}
1 Like
21

You would need to create a user other than admin inside OH3, preferrably same name what you use in your oh client app and nginx conf.
Dunno how I think I saw some post here about doing that in Karaf console but I don’t find it any more.
(ping @hmerk I might be mistaken but wasn it you to write that?)

22

Sorry but I dont understand?

I only wrote that Now there is two levels of security. First is login and pass from nginx and then login and pass for administrator in Main UI.

23

Sorry @mstormi, it wasn‘t me, but i saw that too. Users need to be added on console atm.

24

Of course there is if you do not remove it from nginx.
Since you probably want to access without password, you need to create an oh user (and use that on the client side) inside oh3 and disable auth in nginx.

do you find the post?

EDIT: see Apache Karaf 2.4.5-SNAPSHOT Guides

25

The post you are looking for is here

26

sorry but I still dont understand for what is it for?

I want to have secured connections with OPENHAB.

So if I delete this lines from nginx:
auth_basic “Username and Password Required”;
auth_basic_user_file /etc/nginx/.htpasswd;

then I will ony need to log in by login:ass set in OH3?
Will it secure connection for Basic UI also?

27

yes

it’ll encrypt it with a cert. It won’t do auth again.

28

That’s a rather bumpy migration path in terms of security.
I had a haproxy setup with OH2 which works as expected.
On OH3, the first thing i had done (for some minutes at least) was to remove the basicauth in haproxy, because i thought, this would be handled by OH3 now.
I was wrong and my KNX/Hue/Zigbee-Setup was exposed to the world.

Will there be a usermanagement/basicauth for REST and basicui on the OH3-Side?

cheers

boecko

29

Basic Auth for managing in the REST API is available but turned off by default since in most cases the API Token is more secure.

The Main UI has authentication for management but not for operation. Since the Basic UI is controlled by managed site maps and does not manage OH there is no authentication.

30

I see. But the iOS App needs a user name and password.
How is this supposed to work?

31

@Bruce_Osborne wrote it already

There is a setting to enable it:

image
image815×192 5.4 KB

1 Like
32

After reading all of this I’m still unclear if it’s possible to have OH3 behave as OH2 w/r to authentication using a reverse-proxy that handles authentication. I just want to turn everything off w/r to authentication and have it work like OH2.
I manage my own identities and authentication with Okta, because I don’t trust that there won’t be some security issue with Openhab (or its included libraries) that exposes my internal network. From the reverse proxies perspective it may be desirable in some cases to go directly to OH3 with no further auth. I have further complexity in that I use browsers that don’t understand or support BasicAuth, yet the smartphone apps use this – not sure if they need to be updated to support bearer tokens or something…

2 Likes
33

This is a common misconception. Token based authentication is not more secure - it is exactly as flawed as basic auth. The only difference is that once an attacker listens to you messages he can extract the password from basic auth while with token he only gets the - well - token.
So if you do not reuse your passwords (something you should actually never do) basic auth is on par with token.

@billfor @boecko
You can use this command in the console
bundle:stop org.openhab.core.io.rest.auth
to disable auth and restore the behavior as it was in OH2.
Unfortunately you have to do this every time you start openhab. I’ve already created an issue in october, but so far not much has happened.

2 Likes
34

I only had to add these two lines:

	RequestHeader unset Authorization
	Header add Set-Cookie "X-OPENHAB-AUTH-HEADER=true;path=/;Secure"

Note: I use https

1 Like
35

Generally if you have a Token for a single purpose with restricted authorization for just those purposes it is more secure and more easily isolated. openHAB AAA is currently no where near that level. IT is either unauthenticated read or full Admin access. BTW I work with a commercial AAA system for a good part of my work along with accessing REST APIs for that system and some other things.

36

Thank you! Traefik 2 doc says removing headers within labels isnt supported yet, good to see Authorization is.

EDIT: found a working configuration where login with OH credentials (as admin) doesn’t cause the blank page error, I had to add:

- traefik.http.middlewares.openhab.headers.customrequestheaders.Authorization=""

Although the x-openhab-auth-header is set, OH3 seems not to care about it once you are logged in and will try to parse your proxy’s Authorization header - which fails of course, making all protected resources return 401 (so all /rest, /tiles, etc.).
OH3 seems to really not be ready to be called stable yet with this and the rest hashing performance issues…

EDIT2:
Nevermind, the x-openhab-auth-header must be set to “true” not “1” else OH3 seems to ignore it. Can confirm it sets authorization header to Traefik basicauth, and X-OPENHAB-TOKEN to OH3’s JWT login token.
So my working config for traefik now is:

      - traefik.http.routers.openhab.middlewares=ohauth,oh
      - traefik.http.middlewares.ohauth.basicauth.users=<your htpasswd>
      - traefik.http.middlewares.ohauth.basicauth.removeHeader=true
      - traefik.http.middlewares.oh.headers.customresponseheaders.Set-Cookie=X-OPENHAB-AUTH-HEADER=true
1 Like
37

Is this still required since OpenHABcloud has all requests set with the following:

//tell OH3 to use alternative Authentication header
res.cookie(‘X-OPENHAB-AUTH-HEADER’, ‘true’)

38

I’m still getting a blank page on refresh after logging in basic auth then logging into an OH3 account.
It seems like OH3 frontend code only cares about the X-OPENHAB-AUTH cookie when setting it (getting a token from /rest/auth), not when deleting it. Whenever you are logged out of OH3 or cleanSession() is called, ALL your credentials are deleted (accessToken, refreshToken, localStorage user, pass, Vuex $store user, etc.) regardless of whether they belong to OH3 or to the proxy.
The problem on Android WebView is, refreshing the page after the double login (basicauth + OH3 token) causes cleanSession() to be called for some reason. I’ve now seen this on multiple phones and multiple browsers - Vivaldi, Bromite, Chrome and builtin AOSP WebView browser.

I’m not sure why cleanSession() is called, maybe an event thrown on refresh by WebView but not by desktop browsers the devs used when testing. It does seem like the X-OPENHAB-AUTH implementation is incomplete, causing this bug that many others with problems in the App on iOS and Android have been mentioning since 3.0 release.

39

Currently there is also a bug in chrome that blocks the basic auth credentials to be used when openHAB is accessed via HTTPS and the service work cached the requests. Allow more flexibility in how 401s/407s are handled? · Issue #1132 · whatwg/fetch · GitHub