Incus custom UI app with Keycloak as OIDC provider

1

It’s not clear to me how should I setup OIDC with Incus and my own app. Should I authenticate with JWT or TLS certificate against the API endpoints?

How is this implemented in GitHub - zabbly/incus-ui-canonical: Internal fork of LXD UI used to generate the patches in zabbly/incus ?

Thanks.

2

So what’s your environment exactly and what kind of app is it?
The answer changes a fair bit depending on what the server is configured to use and whether the app is a long running server type app or a client app like our web UI.

3

It’s a web/client app UI kind. More specifically it’s a Blazor app. But I would like to go with “Backend for Frontend pattern” (BFF) and having “long running server” API as backend implementing OIDC to access external Incus API.

Actually, I want to know you opinion on how to implement both, “server” and “client” app?

What is not really clear to me, is the auth flow. I authenticate with OIDC provider, it goes to Incus “oidc/callback” endpoint and then it returns a fingerprint of user client certificate for me? Or how should I obtain it?

Thank you.

4

No, if you perform OIDC authentication then Incus redirects you to the OIDC server which after authentication redirects you to /oidc/callback at which point Incus sets authentication cookies for you which then lets you perform API interactions.

The TLS authentication is an alternative to OIDC, when using OIDC you typically don’t use any of the TLS client certificates or their derived Bearer tokens.

1 Like
5

Okey, I moved forward with this and I just want to clarify a few things.

  1. When I want to login through OIDC provider I should use /oidc/login endpoint? Is this documented somewhere, please?
  2. After successful login I get redirected to /ui path, can I change this behavior?
  3. Can user add his own TLS certificate when already authenticated over OIDC? Maybe he wants to use it as another means of authentication.

Thanks.

6

@stgraber actually one more, please.

What is this endpoint /1.0/auth/identities used in here incus-ui-canonical/src/api/auth-identities.tsx at main · zabbly/incus-ui-canonical · GitHub

7

It might be good to know that this UI is developed by Conanical. There are a few patches on top of the fork that remove branding, but it is not a Linux Containers project.

I think the idea is that in the future there will be many UIs for Incus.

8

That API doesn’t exist in Incus. Our build of the UI disables the pages related to that LXD API.

1 Like
9

Indeed, the OIDC internals could do with a bit more documentation as they start being consumed by other projects.

I think it’d probably be fine to provide the desired post-auth redirection URL, probably as a parameter to the /oidc/login endpoint, though we’ll need to jump through a few hoops to persist that value through a cookie or something as /oidc/login isn’t what ultimately redirects you to /ui, /oidc/callback is and that call is handled by the identity provider.

If you’re authenticated as a full admin (or aren’t using OpenFGA to control authorization), then you can access the /1.0/certificates API when authenticated over OIDC and then add certificate entries through it.

1 Like