X-OPENHAB-TOKEN Use for MainUI Authentication?

Hi,

Does OH3’s MainUI recognize this token and automatically logon user to OH3 instance? Let’s say I create a new user in OH3 called abc and use the account to create an API Token. This API Token is piggy-backed in X-OPENHAB-TOKEN to automatically login abc when the user access MainUI.

You need to look somewhere in UI sources and how it does handle initialization. Token thing you mention is relevant for server, main ui code rely on authorization header.

of course the token has to be in the request header otherwise how are you going to send it over http.

I’m trying to avoid double login 1. OpenHAB cloud and the other one is OpenHab MainUI. My openhab instances have different users created which attach to different openHAB cloud user account.

I have created a pull at Openhab-Core to allow login with generated API Token. Hopefully this is accepted then we can capture this X-OPENHAB-TOKEN to autologin when user landed on MainUI.

@splatch would it be practical to modify code in MainUI to achieve auto login function with the following options:

  1. Behind the scene access GET /auth, like user click on “Admin” login, retrieve all the replied fields like csrf string and etc then POST /auth with X-OPENHAB-TOKEN with the PR above to allow API TOKEN login; OR
  2. Change io.http.auth with “json=true” on query string for GET /auth, which will return all the CSRF, code but in JSON form instead of HTML template page.

I have a use case for the above which could be useful for RBAC (RBAC model in openHAB (and potential security vulnerability found)) later so that we can do “SSO” with assigned API token through mobile app. Otherwise it will be glad that you can give some other guidelines on how to implement this and hopefully I can provide some helps. Or it has already implemented which I am not aware of . Thanks

Looking forward to when this gets merged!

The SSO functionality can be achieved through mix of several things - i.e you can come with JWT trusted by OH instance and launch a new OH session based on it and permissions implied from token. The main point beside AuthenticationProvider was exactly that.
New authentication methods can be added with their own endpoints, issue is - all existing clients expect one way to log in.