@olivierlambert Thanks a lot.
We have not SPOF and full fiber 100Gb network spine/leaf infrastructure so I will give it a go (currently we are only on a test plateform so I do as much as I need )

@olivierlambert Can't wait. V6 Gui is really nice
Most of my colleagues are saying it's sexier than vcenter

If you have an issue authenticating with Fortiauthenticator and OIDC, follow this steps.
First of all : you need a real certificate signed by a legitimate authority on the fortiauthenticator. Self signed will not work ! No ifs or but (beside fumbling in the code to allow self signed I suppose)
You might have to import the certificate as a bundle with it's direct signee (not the full chain)

After that just log into your FAC and go to : Authentication/Oauth Service/Portals
Create a new portal with your specific configuration if needed (default should be fine for a test)

go to : Authentication/Oauth Service/Policies

Create a new policy and select the Portal you created in the previous step

go to : Authenticator/Oauth Service/ Relying Party

Create a new Relying party
Select Confidential and Authorization
Select the policy you created before

Select Relying Scope and add "openid"
Select Add Claims and add a openid claim named "preferred_username" and user attribute "username" (if you select another user attribute like email, you will need to adjust the configuration in XOA)
Take note of the Client ID and Client Secret

Now in XOA, go to Settings/plugins/Auth-oidc plugin

Input the autodiscovery of your FAC
https://your-fac-FQDN/api/v1/oauth/.well-known/openid-configuration/

Input the client ID and client secret from your Relying Party in the FAC

Enable the plugin and you should be set

I'm starting to think that something is wrong.
Everywhere I check, I can see that the SAML request from the SP should have a signature of some sort.
It doesn't seem that there is anything of the sort in our case.
We are using the opensource for preproduction and are waiting for a pro license (paperwork on it's way) so maybe there is something wrong in the implementation ?

@probain Thanks, tried to have new line at the end with no luck. I already had found your guide I think and tried also to add the -----BEGIN CERTIFICATE----- & -----END CERTIFICATE----- and also newline withor without the certificate line without luck.
When inspecting the saml request and checking on other google research, I can see that the request doesn't have a signature like this <ds:SignatureMethod Algorithm="XMLSecurity::Document::RSA_SHA1" />
I'm not sure if this is normal or not

I was able to configure Keycloak with OIDC without any issue.
We also have a working configuration SAML for our vcloud so we know our setup should be working.
However with XOA we fail whatever the setting we use.
If we use Client Signature and copy the public key in the approriate field in XOA we get Invalid Requester in Keycloak and Invalid_Signature error
If we disable Client Signature, we reach the authentication page and can login, however when we are redirected to the /signin/saml/callback we get an Internal Server Error and in XO logs we have the following
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: Error: Invalid signature
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: at SAML.validatePostResponseAsync (/opt/xo/xo-builds/xen-orchestra-202501241022/node_modules/passport-saml/src/node-saml/saml.ts:792:17)
Feb 25 16:51:24 XEN-ORCHESTRA xo-server[49969]: at processTicksAndRejections (node:internal/process/task_queues:95:5)

I found a old topic of 2022 with someone being able to have it work with Keycloak but the user has not been active since then and did not indicated how he made it work.

When I check the SAML request and Response, they all look fine and I can see my user shown in the field NameID.
Only issue seems to be the expected signature in Xen-Orchestra.

Couldn't find any guide for XOA & Keycloak online sadly.

@nathanael-h In the contexte of SSO this makes sense to not logout the session of the IDP as it might be used for other SP but usually when one disconnect from an application (like logging out from Google), you get an option to log out from all other application.
This would send the logout to the IDP ?

@olivierlambert We are in the process of purchasing entreprises licenses for a 4 hosts cluster. It's not a big deal so I'll wait untill we have support to open a ticket

We were able to connect with OIDC via Keycloak with this guide (https://xen-orchestra.com/blog/xen-orchestra-5-80/ Olivier Lambert being on top of everything as usual )
Unfortunately when we disconnect, the user is not disconnected from Keycloak and the session stays active.
We are using the .well-known/openid-configuration url so the logout url should be taken into account but we don't see any log showing further communication between XOA and Keycloak when we logout from XOA.
Any idea is appreciated

@olivierlambert Can't wait. V6 Gui is really nice
Most of my colleagues are saying it's sexier than vcenter

@DustinB Thanks. Didn't realized the /v6 was available on XOA. Thought it was specific on the host.
Unfortunately nothing works for users who are not admin (users can't even view their VM)
There is still a lot of work for permission like Olivier mentionned.

@olivierlambert Thanks Olivier. Unfortunately in our configuration XO Lite cannot be used.
So it will be XO 6... 2025 ?