OICD logout not working

[Slydder]

hey all,

we have a working PVE 8 install with a keycloak authentication backend that works just fine except for logging out. even if we logout on the backend pve stays logged in. does anyone know how to fix this? not a very secure way to handle access when logging out doesn't work.

thanks,
chuck

 

[fabian]

currently, logging out is done purely client-side. this would require implementing something like https://bugzilla.proxmox.com/show_bug.cgi?id=5478 to trigger expiry of sessions/tickets via an external request, and hooking that into the OIDC flow.

 

[Slydder]

Wow. Need time to wrap my head around this one. Logging in per SSO is only half the job. Didn't think I would see half measures in PVE. If someone logs out in the backend then EVERYTHING they are logged in with must be logged out. otherwise the system is only half secure. Strange.

 

[t.lamprecht]

the backend pve stays logged in

The PVE backend does not stay logged in, it has no concept of sessions, only the client (browser) has the required secret of the ticket, so one cannot recover the login purely from the backend.

So what do you mean here? Do you mean that if you log out, and then log back in Keycloak skips (re-)asking the credentials as the browser and user pair gets mapped to a still open session from keycloak?

If, then it seems that you should look into how to configure Keycloak to always ask for credentials on OIDC requests, as that is the only safe way to implement this centrally.

 

[fabian]

to further note: clients on RPs being logged out via a requests or session state changes on the OP side is an optional part of OIDC, and PVE doesn't indicate it supports that (yet) anywhere.. there's multiple ways to implement it, but almost all of them (except RP-initiated logout, which is not what you want I think ) would require server-side session management first, which the linked enhancement request is about..

 

[Slydder]

The PVE backend does not stay logged in, it has no concept of sessions, only the client (browser) has the required secret of the ticket, so one cannot recover the login purely from the backend.

So what do you mean here? Do you mean that if you log out, and then log back in Keycloak skips (re-)asking the credentials as the browser and user pair gets mapped to a still open session from keycloak?

If, then it seems that you should look into how to configure Keycloak to always ask for credentials on OIDC requests, as that is the only safe way to implement this centrally.

I was speaking of the keycloak/OIDC provider as the authentication backend in this instance.

As for requiring relog each time login is pressed makes absolutely no sense whatsoever, as it negates the entire concept of SSO.

 

[Slydder]

to further note: clients on RPs being logged out via a requests or session state changes on the OP side is an optional part of OIDC, and PVE doesn't indicate it supports that (yet) anywhere.. there's multiple ways to implement it, but almost all of them (except RP-initiated logout, which is not what you want I think ) would require server-side session management first, which the linked enhancement request is about..

I would have to reread the OIDC standards but I do believe it is quit similar to SAML in this regard. Will reread it and get back to you on this point.

 

[fabian]

https://openid.net/specs/openid-connect-frontchannel-1_0.html
https://openid.net/specs/openid-connect-backchannel-1_0.html

are probably what you are after (actively logging out on the RP side if a logout occurs on the OP side)

there is also

https://openid.net/specs/openid-connect-session-1_0.html (general session management, including monitoring of changes of the state on the OP side by the RP)

and

https://openid.net/specs/openid-connect-rpinitiated-1_0.html (which would be logout on PVE triggering logout on the OP side)

 

[t.lamprecht]

I was speaking of the keycloak/OIDC provider as the authentication backend in this instance.

Yeah, but as said that has no state, and can per definition not stay logged in, the browser client can OTOH.
It sounded like you observed something that broke that, that's why I asked.
Triggering a log-out request for OIDC realms to the IDP when a user clicks the Logout button is certainly something that can be added, and FWICT it would not require session management at all.

As for requiring relog each time login is pressed makes absolutely no sense whatsoever, as it negates the entire concept of SSO.

That's IMO a very limited interpretation of SSO, the main concept is to have a single provider for sign-on for many/all services without having to register/keep credentials for each service; staying logged in is an additional convenience feature, if doing so makes really sense security wise is for the local site admin, or their higher ups, to decide; but its absence can certainly make sense for some and might be even a base requirement for security critical sides. And IIRC keycloak allows having different restrictions and requirements for different RPs.

 

[Slydder]

https://openid.net/specs/openid-connect-frontchannel-1_0.html
https://openid.net/specs/openid-connect-backchannel-1_0.html

are probably what you are after (actively logging out on the RP side if a logout occurs on the OP side)

there is also

https://openid.net/specs/openid-connect-session-1_0.html (general session management, including monitoring of changes of the state on the OP side by the RP)

and

https://openid.net/specs/openid-connect-rpinitiated-1_0.html (which would be logout on PVE triggering logout on the OP side)

Yes, the last is the one I just finished rereading as well as

https://openid.net/specs/openid-connect-core-1_0.html (section 15.7)

Which still makes little sense to me from a security standpoint. But they wrote the standard so....

Still doesn't fix the fact that if we disable an account on the backend then the pve session should be signaled to terminate.

will have a look what we can figure out here to fix this lacking aspect in security.

 

[t.lamprecht]

Ah, OK, when you write backend you mean the (Keycloak) IDP/OP; not the PVE backend.

Yeah, the backchannel one would be relatively easy to implement directly in PVE once #5478 is implemented, fontchannel does not make much sense with the current PVE architecture, FWICT.