Support for OIDC / oauth2 third-party identity provider

[farfade]

Hello,

I'd like to be able to make openhab3 trust a third-party identity provider instead of only relying on its own internal identity provider.

My feeling is that the hard part of the job has already been done (supporting oauth2 for the REST API).

Regards,

farfade

[ghys]

Not sure exactly what you're after, but basically I see two possible approaches:

• making the API auth layer recognize the access tokens issued by your external authorization server - if they are JWTs, it could be as "simple" as accepting those with compatible claims (in particular, having a scope like "admin" and a role claim with a set of roles, either user or administrator) and signed by a trusted authority (this method assumes the tokens come from the internal auth provider but it could be extended with a system of trusted authorities sourced from configuration). Note that this alone would not allow you to sign in to your external IdP from the UI - it would only let for instance another app make authorized requests to openHAB with their own tokens
• another approach would be to add support for assertion flows/grant types (RFC 7521) to the token endpoint, accepting for instance an identity token from the external authorization server/IdP, validating it somehow, and then issue the usual tokens. In that case the UI login flow could also be modified to redirect, automatically or manually (i.e. with a button), to the external IdP for authentication, receive the assertion with a callback and call the token endpoint to open a session in the internal auth provider. But apart from that, few other changes would be needed since the client would be oblivious of the identity provider the user authenticated against. There would probably be a need to automatically create users in the internal user registry to still allow the session & API token management from the profile page. The password change feature should also be disabled for these users since they have no locally-managed password.

Since the internal IdP isn't OIDC compliant due to constraints like mandatory HTTPS that are not the norm for openHAB installations, standards like OIDC Federation 1.0 cannot be implemented easily. However support for OIDC (including the discovery part) as a trusted issuer of assertions in the second scenario could be, provided these constraints are not a problem in your use case.

[farfade]

Wow, I see your ideas are clearer than mine !

Actually my use-case is about single-sign-on :

• if I'm not authenticated, the front app redirects me to the third-party identity provider
• I authenticate once to the third-party identity provider
• the identity provider delivers something that the browser, on a PC or on a Android device (let's say to simplify : Chrome even if I'd like to say Firefox) can store and that enables openhab (and a lot of other apps) to understand who I am

I eventually ended-up in thinking that OIDC and oauth2 are the most promising techs to do that (with you secondary approach for openhab, and supporting also more elaborated things like authorization delegation, as roles like admin and user started to appear).

[hmerk]

Isn‘t this completely against the approach of having a „Intranet of things“ ? openHAB should mainly run without the need of having a working internet connection, but this request creates a dependency on that. I would agree if it is seen in context with myopenHAB remote access, but not for pure local access. Just my 2 cents.

[farfade]

Actually it does not. An identity provider can be self-hosted, just as anything else.

And offering a feature does not mean it is mandatory to use it : as ghys told it, openhab already implements a basic identity provider. The feature would just let guys that want to replace it by another one do it (with a self-hosted one or a "cloud" one).

To me, it is a self-contained identity provider that does not make sense : you cannot reuse the identity stored in it :)