Product/components used and version/fix level:
Cumulocity 10.15, licensed
Detailed explanation of the problem:
Working with a team trying to design out a “kiosk” or “dashboard” for customer installations which would display dashboards built within the c8y UI. Our goal is for this device (like a Raspberry Pi) to be non-interactive where the customer will not need to re-login periodically to load the UI.
As a concept, we would like to connect this RPi as a device itself to c8y and push the relevant dashboard URL to the device. This part seems straightforward.
The challenge, however, is how to authenticate/authorize that device to the c8y UI if it has only (to this point) been a device.
On additional note is we are securing c8y with Azure B2C as a SSO-only schema which requires MFA which would make a non-interactive login (e.g. basic auth) a non-starter.
One PoC we’re thinking through: Can we push an authorization cookie/header to the device which can be used, in turn, to authorize access to the UI?
Any thoughts, ideas, etc, will be welcome!
Other ideas could explore include just building our own custom web app and use the APIs. However, we would prefer to allow customers to create their own dashboards (in c8y) which would complicate things.
We are also looking for a similar kind of solution, and any leads to this are appreciated.
On additional note is we are securing c8y with Azure B2C as an SSO-only schema which requires MFA which would make a non-interactive login (e.g. basic auth) a non-starter.
I only know the possibility of logging in via hardcoded user/password. There is a tutorial about it: Tutorials - Cumulocity IoT Guides
As you can configure a user in Cumulocity even if SSO is used, you can use this user to login with basic auth. When you really need SSO access to for example receive data from some other source, you can modify this code to exchange the credentials with your SSO provider and then inject the token by using the CookieAuth strategy:
// some logic to get the token
// set the token as a cookie called authorization in JWT format <- This might be hard to get but I would try to look at the current workflow and see how the set-token is called there.
return loginService.login(new CookieAuth()); // CookieAuth is exported from Client
Easiest way would be to create a Basic Auth user for this cases.
Thanks, Jan! We’ve looked at the hardcoded option and initially wrote it off as a security issue. However, we may be able to make it more secure by passing those credentials via a device command.
Our next challenge with the above tutorial would be presenting the dashboards created by the end user in that app. Something to invistigate.