SAML Auth with Azure AD
-
Don't see it officially documented anywhere so I'll put down what worked for me and where I'm stuck. Using fully updated community edition (Xen Orchestra commit a4118, xo-server 5.100.0, xo-web 5.101.0).
XO instance is behind reverse proxy (Nginx Proxy Manager) pointed to Web UI's IP, port 443, HTTPS with websocket support and forced HTTPS redirection. Cert is valid. Public URL confirmed working.
-
Azure Active Directory > Enterprise applications > New application > Create your own application > Name: Xen Orchestra, Type: Non-gallery > Create
-
Azure Active Directory > Enterprise applications >Xen Orchestra > Users and groups > Added myself
-
Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > Basic SAML Configuration >
Identifier (Entity ID): https://<Public URL>
Reply URL (Assertion Consumer Service URL): https://<Public URL>/signin/saml/callback -
XO > Settings > Plugins > auth-saml (v0.9.0) >
Certificate: Copied contents of Certificate (Base64) (from Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > SAML Signing Certificate)
Entry point: Copied from Login URL (from Azure Active Directory > Enterprise applications > Xen Orchestra > Single sign-on > SAML > Set up Xen Orchestra)
Issuer: Copied from Application ID (from Azure Active Directory > Enterprise applications > Xen Orchestra > Properties)
Username field: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
Don't request an authentication context: Enabled (tried disabled too)
With any other Issuer I try, Microsoft gives an error that the application was not found.
With the application ID, it's found but I get the following error:
"Sorry, but weβre having trouble signing you in.
AADSTS50011: The reply URL 'http://<Public URL>/signin/saml/callback' specified in the request does not match the reply URLs configured for the application '<Application ID>'. Make sure the reply URL sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/urlMismatchError to learn more about how to fix this. "Issue is, everywhere I can see, from the reverse proxy to my enterprise app, I'm using HTTPS. For some reason XO is sending the SAML request as http.
I've tried replacing the HTTPS reply URL under Azure Active Directory > App registrations > Xen Orchestra > Manifest with HTTP but it won't save. Was able to add the HTTP one on top of the HTTPS one, but same error.
I see a single mention of it here: https://github.com/vatesfr/xen-orchestra/issues/3822 as the last comment on the issue with no followup.
-
-
You should up the issue to bring attention on it (and link to this thread).
edit: obviously, there's no guarantee whatsoever there's a response, but it's best effort in the community
-
@olivierlambert thanks for the heads up, added a comment on there and linked back
-
-
@fanuelsen thanks! Updated and confirmed I can now customize it.
Trying to SAML auth now gives me a blank page with "Internal Server Error" on it instead, with the displayed URL being the (correct) callback one. Refreshing the page shows a quick Microsoft auth URL then the error.
Not sure how to proceed here, would help if we could confirm what "Entry point" "Issuer" should be mapped to regarding Azure AD so I could at least rule out the config on XO being the issue. I tried checking Audit and Logs but there wasn't much info on why the auth failed.
-
Have you checked
xo-server
output? -
@olivierlambert sorry for the delay there! Relevant portion of the logs (extracted via journalctl -u xo-server.service)
Aug 08 14:33:24 xo-ce xo-server[517]: Error: error:0909006C:PEM routines:get_name:no start line Aug 08 14:33:24 xo-ce xo-server[517]: at Verify.verify (node:internal/crypto/sig:230:24) Aug 08 14:33:24 xo-ce xo-server[517]: at RSASHA256.verifySignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:140:24) Aug 08 14:33:24 xo-ce xo-server[517]: at SignedXml.validateSignatureValue (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:460:20) Aug 08 14:33:24 xo-ce xo-server[517]: at SignedXml.checkSignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/xml-crypto/lib/signed-xml.js:397:15) Aug 08 14:33:24 xo-ce xo-server[517]: at validateXmlSignatureForCert (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/xml.ts:103:14) Aug 08 14:33:24 xo-ce xo-server[517]: at /opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:730:41 Aug 08 14:33:24 xo-ce xo-server[517]: at Array.some (<anonymous>) Aug 08 14:33:24 xo-ce xo-server[517]: at SAML.validateSignature (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:729:18) Aug 08 14:33:24 xo-ce xo-server[517]: at SAML.validatePostResponseAsync (/opt/xo/xo-builds/xen-orchestra-202208032035/node_modules/passport-saml/src/node-saml/saml.ts:785:17) Aug 08 14:33:24 xo-ce xo-server[517]: at runMicrotasks (<anonymous>) Aug 08 14:33:24 xo-ce xo-server[517]: at processTicksAndRejections (node:internal/process/task_queues:96:5)
I looked up "Error: error:0909006C:PEM routines:get_name:no start line" in relation to passport-saml and read through a ton of discussions but couldn't find a conclusive solution. I am copying the contents of the Base64 .cer file in their entirety and triple checked they are correct. Tried converting from UTF-8 to ANSI and ASCII as well as replacing "CERTIFICATE" with "PRIVATE KEY".
One thing to note: When copying the cert text back from the XO field, the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- are not in their own lines. I saw this mentioned in a couple discussions such as here. I did try manually replacing the spaces between the hyphens and the string with /n but it wasn't parsed correctly when entered via the web UI.
-
Does it ring a bell @julien-f ?
-
For what it's worth, most Web UIs I see that take in certs use a text box/area rather than a text field which (directly or indirectly, not sure) preserves the line breaks in the cert. Everywhere I'm seeing, a text field doesn't seem to preserve the needed line breaks when its value is stored in a string.
Not sure which file(s) I'd need to edit to test a fix for this as I'm not the strongest with web development, but would be willing to try and report back.
-
Okay thanks for the feedback Let's see if we can fix it with a text box/area instead of a simple text field!
Re-ping @julien-f
-
It's now fixed, please let us know if you have other issues
-
@julien-f confirmed fixed, thank you! Copy/pasted the Azure AD enterprise app's base64 cert in again and saved to get it working. After updating XO of course.
-
Yay! Great news, thanks for the feedback @dant123 !