Support SAML2

[bensmrs]

Corporate loves its SAML2. This issue is here to start the discussion of SAML2 integration into Incus. Do we want that? Shall we only use it to authenticate users and not for authorization? Shall we also use it for authorization; in which case, is the assertion format really adapted to the granularity of rights some of our authorizers provide? Shall we have an assertion giving a (list of) role(s)/group(s)? Where are these groups defined? a configuration mapping? a scriptlet?

Looking forward to reading what y’all think. To me, even in 2024, not supporting SAML2 can be a no-go for big corporate players.

[stgraber]

In my experience so far, only supporting OIDC hasn't been a problem at all.

Most corporate environments I've had to integrate with lately tend to use Active Directory, either self-hosted or in the cloud. In both cases, Active Directory Federation Services (or Entra ID App) supports OIDC directly.

For the few environments that can't handle OIDC directly or where some of our OIDC requirements exceeds what the platform offers natively, specifically around device code authentication, then I've found that using Keycloak as an intermediary works pretty well and then allows for basically anything to be used for authentication, whether it's a local LDAP, Kerberos, generic SAML2, generic OIDC or a number of pre-defined cloud identity providers.

It wasn't exactly painless to get OIDC working properly, especially for the device code flow use case (as needed for the CLI), so I'm somewhat reluctant to doubling all of that logic by adding native SAML2 support alongside it when it's so easy to deploy Keycloak or a similar service and just have that chain to whatever the organization may prefer.

(In general OIDC is also a better fit for us as it's based around JSON/JWT, uses RESTFUL APIs, ... SAML2 with its SOAP based API and XML doesn't feel too familiar ;))

[stgraber]

During my limited research (1-2h) on SAML2, I also couldn't find a good answer to how to handle our CLI authentication needs (incus remote add) where we want the client to be able to retrieve the needed authentication tokens without that client itself running a web server and without just pushing the problem onto the server.

OIDC handles that quite nicely with the device code authentication, the user gets a one time code displayed as well as a URL to access the authentication provider, they can then open that URL on any machine and go through the authentication flow, once it completes, the client gets notified and receives the needed tokens that it can then use to talk to the server.

This flow is important to us as we want it to be possible to SSH to some remote server, then run incus remote add from there, that remote server is therefore unable to start a local web browser for us to authenticate, so the URL must then be open on another device completely and be able to go trough the auth flow with that auth flow resulting in the remote server getting the token.

This requirement effectively eliminates any authentication method which relies on a temporary web server + redirect to a localhost address as is common with some other tools.

(Authentication for the web UI tends to be a lot easier to implement as it doesn't have this kind of requirement)

[bensmrs]

Most corporate environments I've had to integrate with lately tend to use Active Directory, either self-hosted or in the cloud. In both cases, Active Directory Federation Services (or Entra ID App) supports OIDC directly.

Yeah I’ve gotta say my experience may be a bit of an oddity. Without telling too much, I’ve worked at places where Apereo CAS is the only thing deployed (and in some cases deploying a new piece of auth/autz software may take months to get formal approval). It becomes less of an oddity if you consider academic institutions, at least in France, where Apereo CAS is the way to go. CAS obviously supports OIDC (but there are rather painful finicky details), but we’re not doing authorization with OIDC in Incus, right? aren’t we only using it for authentication?

(In general OIDC is also a better fit for us as it's based around JSON/JWT, uses RESTFUL APIs, ... SAML2 with its SOAP based API and XML doesn't feel too familiar ;))

Come oooon, you grow to love it :þ

During my limited research (1-2h) on SAML2, I also couldn't find a good answer to how to handle our CLI authentication needs (incus remote add) where we want the client to be able to retrieve the needed authentication tokens without that client itself running a web server and without just pushing the problem onto the server.

OIDC handles that quite nicely with the device code authentication, the user gets a one time code displayed as well as a URL to access the authentication provider, they can then open that URL on any machine and go through the authentication flow, once it completes, the client gets notified and receives the needed tokens that it can then use to talk to the server.

This flow is important to us as we want it to be possible to SSH to some remote server, then run incus remote add from there, that remote server is therefore unable to start a local web browser for us to authenticate, so the URL must then be open on another device completely and be able to go trough the auth flow with that auth flow resulting in the remote server getting the token.

I think there’s only one thing missing in SAML2: the device actually polling the IdP/STS for its tokens. Nothing really prevents you to:

• Have the client ask the server for some tokens
• Have the server answer “use a browser to go to this url (https://.../validate?token=xxx)”, with a single-use token identifying the device
• Have the user go to this URL, which redirects to the IdP
• Have the user authenticate, then POST the resulting assertions to the server
• Have the server verify the assertions and (if relevant) give the client its token (or have the client poll the server until it gives back the token)

I’m surely missing something obvious in the flows Incus uses, as I’ve not yet dug into the authentication parts of Incus. And coming from a SAML world, there are unspoken/obvious things OIDC people have in mind that I don’t :)

But that’s just for authentication, the authorization part is also quite important (and then OIDC seems out of the game in Incus [why?]).

[stgraber]

Yeah I’ve gotta say my experience may be a bit of an oddity. Without telling too much, I’ve worked at places where Apereo CAS is the only thing deployed (and in some cases deploying a new piece of auth/autz software may take months to get formal approval). It becomes less of an oddity if you consider academic institutions, at least in France, where Apereo CAS is the way to go. CAS obviously supports OIDC (but there are rather painful finicky details), but we’re not doing authorization with OIDC in Incus, right? aren’t we only using it for authentication?

Correct, we're using it for authentication only. Authorization is then handled through OpenFGA or through the authorization scriptlet now.

We could in theory play with OIDC scopes to handle some level of authorization, but in practice it has nowhere near the granularity that we need, so while we could (and maybe at some point will) support basic mapping between scopes and cluster-wide roles, it doesn't seem practical to use those for fine grained access to projects or instances.

Come oooon, you grow to love it :þ

Haha, no you don't! I did spend a solid 5-10 years dealing with far more SOAP and XML than I ever wanted, it really doesn't grow on you ;)

I’m surely missing something obvious in the flows Incus uses, as I’ve not yet dug into the authentication parts of Incus. And coming from a SAML world, there are unspoken/obvious things OIDC people have in mind that I don’t :)

So I think the one thing that your flow doesn't allow, which unfortunately is still reasonably common when you consider folks accessing remote servers over SSH is that the browser that the client uses may well have access to the IdP but NOT the target Incus server.

With OIDC device token, that's not a problem, the CLI tool polls the IdP, the user separately grants access for that device code through the IdP, then the CLI receives the token and can access Incus, the user's cell phone or whatever they used to access the IdP never needed to talk to Incus.

[bensmrs]

We could in theory play with OIDC scopes to handle some level of authorization, but in practice it has nowhere near the granularity that we need, so while we could (and maybe at some point will) support basic mapping between scopes and cluster-wide roles, it doesn't seem practical to use those for fine grained access to projects or instances.

That’s where I wanted to take the discussion. Good to read it’s not out of the picture.

Haha, no you don't! I did spend a solid 5-10 years dealing with far more SOAP and XML than I ever wanted, it really doesn't grow on you ;)

Well, to each their own I guess :)
I won’t start the data exchange format debate, one of my favorites (I use vim btw)

So I think the one thing that your flow doesn't allow, which unfortunately is still reasonably common when you consider folks accessing remote servers over SSH is that the browser that the client uses may well have access to the IdP but NOT the target Incus server.

Fair enough.

Although it can be hard to use for remotes/the CLI client, does it still mean we shouldn’t use it anywhere?
In any case, if SAML authorization becomes a thing in Incus, cluster roles should have been implemented first, and we might as well start with OIDC authorization then…