Hello Team, One specific SAML is bugging us more than a WEEK
Hey Team,
We've been working on integrating ADFS for a customer and encountered an unusual exception that's got us stumped. The error code is
SAML-nuo0vphhh9.
Interestingly, when we attempted to reproduce the issue using our test ADFS server, everything worked fine, which was a bit disappointing 😦 However, the problem persists in the customer's environment. We've compared the decrypted assertions between our ADFS response and the customer's, but nothing stood out. We'd really appreciate any insights or help you could offer. Thanks a lot!
19 Replies
@Zitadel Staff
Hm tricky to tell, have you compared the settings on the adfs side?
Btw. this is a community forum, so even without tagging we try to respond 😉
Yes, did compared the ADFS configuration as well, but couldn’t find anything specific which could make this issue. One thing, zitadel uses UTC regardless which timezone zitadel server is configured on right?
thanks . @FFO . 🙂 :zitadel: I ran the application in local debug mode with production dump and did some hackaround to disable user-agent check.
the root issue
cannot validate signature on Assertion: Could not verify certificate against trusted certs
for some reason, we were not getting this exception even after running production and local application in debug level mode.
GitHub
cannot validate signature on Response: Could not verify certificate...
Hi, I am using version v0.4.5, i got redirected on /saml/acs where my request returns with a forbidden code, and this error happens intermittent, below is the IDP metadata and IDP response, based o...
getting the exception over here.
Hm but would indicate that the cert used to verify the sig is not working
What could be the possible problem here?
Usually its down to encoding errors in the cert.
How did you setup the trust here?
so the client shared their adfs metadata file , and from our side we did the base64 and configured in zitadel,
and to client we shared the zitadel metadata
Thank you , issue got resolved.
The certificate mentioned in the decrypted assertions has a signing certificate on it, which is not mentioned in the metadata file they shared. And in our test ADFS case, it's the same. (metasaml signing cert=assertion certificate)
And Zitadel is considering only the signing certificate which is mentioned in the metadata file; it will ignore the one that is present in the assertions. So, I changed their metadata.xml to include the signing certificate which is mentioned in the assertions.
This situation happens when IDP certificate rotation occurs, where they don’t update the federated metadata xml with the latest signing certificate. I don’t see any point in keeping it different either. It would have worked if Zitadel reads the assertion's signing certificate to validate the assertions. So technically, it can be a bug or as per SAML design as well.
Just out of curioisty could this also affect you?
https://discord.com/channels/927474939156643850/1285939724808355880/1286557249518567424
@ffo, issue got resolved. thanks buddy ❤️
this was different, where some reasons, our client ADFS SAML is not accepting sha256
it got fixed by switching to sh1
Ah perfect, thanks for sharing 😄
@FFO not sure if it’s bug or as per design, and also library errors are not being shown even in debug
Hm that can be both 😄
We are talking about the saml part, right?
Yes, validating saml assertions
@stebenz might know the best.
What do you think of https://discord.com/channels/927474939156643850/1287769489269592084/1288132573700292673 ?