I have just migrated a week ago from XOCE to XOA paid support this week and all the process was fine except the auth with the saml plugin.
The commit I had in XOCE was [XO 5d92f - Master 3f604]. I compiled it the first week of this november so it wasn't very outdated.

We use the MSEntraID SAML authentication and it was working fine in XOCE since at least one year ago.

Mi process was like this:

• First, I installed XOA and imported the configuration from my old XOCE. Everything was fine and all was imported succesfully (backups, users, acls, etc.), including my plugin configurations.
  Note that I reused the https server certificate/private key and used the same IP and the same DNS (beacuse I turned off my XOCE before starting XOA).

• Everything was working fine except the saml auth plugin. I had the same "Internal server error" problem.
  I looked at the xo-server logs and the error was "invalid document signature" so, as Olivier said, we changed the configuration in MSEntraID to set the "Sign SAML response and assertion" on.

• Once we changed the configuration I thought the plugin would work again, but surprisingly not. If I try again SAML validation i still got the "Internal server error".
  When i checked again the xo-server logs I saw ahother exception, this time with the error "SAML assertion audience mismatch" and a reference to the issuer configuration of the plugin.
  The exact error I got from xo-server logs using "journalctl -u xo-server -f -n 50" was: "xoa xo-server[2370]: Error: SAML assertion audience mismatch. Expected: <id-of-MSEntraID-xo-validation> Received: spn:<id-of-MSEntraID-xo-validation>"I didn't understand this, because the configuration was exactly the same as I had in XOCE. In fact, I turned off XOA and turned on again XOCE just to test the plugin. The result was that in XOCE the plugin worked well.

• After many tries and some time of impostor syndrome we found the solution:
  I don't know why, but in XOCE compiled at the beginning of november you have to configure the issuer field of the plugin with the <id-of-MSEntraID-xo-validation> (8digit-4digit-4digit-4digit-12digit).
  Instead, in XOA deployed also this november, you have to set the issuer field to you XOA URL: https://<xo.company.net>/

I hope this will help, because it was a pain in the neck for us this week.

BTW: @olivierlambert this "Internal server error" coming from an uncatched exception in the plugin was not very descriptive. Even a generic try-catch block just to show in the web interface the error would help...

P.D.: I'm from Spain, so I do my best with my english
P.D. 2: Great job with all the Vates virtualization stack! You are the best!

Dani

I've followed it and it worked, however there's two caveats:

1. You need to use XOA 5.112, which is on the latest channel as today and not the stable channel.
2. You need to Sign SAML response and assertion. To do that, Go to Microsoft Entra ID → Enterprise applications → Xen Orchestra → Single sign-on → SAML.

After those settings I could login with Azure ID / Entra ID / Whatever Microsoft calls today.

Sorry for that late response, but yes, latest version is working fine and has solved the issue.

Thanks for the fix.

Edit: Removed doubled screenshot

Edit: thank you!

Hello,

I've updated the cert with signed assertion and response

I also tried with a brand new certificate.

Unfortunately, login is still failing.

From xo-server:

Oct 09 08:11:17 xo-ce xo-server[272092]: Error: SAML assertion audience mismatch. Expected: 1671ff50-10e1-4a02-a0c5-4ed298898281 Received: https://XO_DNS_RECORD/
Oct 09 08:11:17 xo-ce xo-server[272092]:     at /opt/xo/xo-builds/xen-orchestra-202510090759/node_modules/@node-saml/node-saml/src/saml.ts:1264:18
Oct 09 08:11:17 xo-ce xo-server[272092]:     at Array.map (<anonymous>)
Oct 09 08:11:17 xo-ce xo-server[272092]:     at SAML.checkAudienceValidityError (/opt/xo/xo-builds/xen-orchestra-202510090759/node_modules/@node-saml/node-saml/src/saml.ts:1259:8)
Oct 09 08:11:17 xo-ce xo-server[272092]:     at SAML.processValidlySignedAssertionAsync (/opt/xo/xo-builds/xen-orchestra-202510090759/node_modules/@node-saml/node-saml/src/saml.ts:1151:32)
Oct 09 08:11:17 xo-ce xo-server[272092]:     at SAML.validatePostResponseAsync (/opt/xo/xo-builds/xen-orchestra-202510090759/node_modules/@node-saml/node-saml/src/saml.ts:808:16)

And here is the plug-in configuration:

I'm not expert at all in SAML, sorry not being able to debug deeper.

We have updated the doc when you saw the impact. Sorry for the inconvenience:
https://github.com/vatesfr/xen-orchestra/pull/9084/files#diff-6319d6b750c3bdbca61a9d9a1577a8aa4fa3a8a37764b91aef4672f69403baa4R221

pierrebrunet289 opened this pull request in vatesfr/xen-orchestra

closed chore: update doc for SAML due to breaking changes in config #9084

Yes it was. You need to be sure that your SAML provider used the signed SAML assertion.

Examples in Keycloak then Azure respectively:

Has the saml-auth plugin updated recently ?

Using XOCE, commit c0065, it was working fine. Updating today to latest release, SAML authentication (Microsoft Entra ID), is not working anymore, I land on a page with a
'Internal server error' message.

Thanks,

I just didn't get immediately that you also need to specify the callback URL in the XO plugin settings, not only in the enterprise application in the Microsoft portal.

My XO is behind a reverse proxy with a Let's Encrypt certificate, but it is also working with a self-signed certificate and a local DNS record.

@olivierlambert Might be worth an addendum in the official documentation with specific screenshots for Microsoft Entra?