Interesting approach! (Full disclosure, I work for a Stytch competitor.)
Some initial thoughts:
* nice to ship an OSS version and I appreciated that the OSS limits were clearly called out (only supports node, 1MB limit on XML payload size, you have to update it regularly)
* critically important to understand that a solution like this isn't the whole enchilada (and they declare that a couple of places): "important to enforce critical checks such as strict Audience and Issuer validation" from https://samlshield.com/docs/get-started-open-source So this isn't a set -and-forget solution.
* replay attacks better protected against by using unique identifiers and invalidating when you've seen one before (they just check for time based validity). But I get that's hard to do with a proxy!
I'm all for improving security. SAML unfortunately is going to be around for a long long time and the protocol won't see any updates. This seems like a good step forward in examining SAML requests/responses, even if there are limits to the proxy approach.
Absolutely and that’s a key limitation of the proxy model. Since the proxy doesn’t have the decryption keys, encrypted assertions need to be handled inside the app. I just updated the security coverage page to call that out explicitly!
> * replay attacks better protected against by using unique identifiers and invalidating when you’ve seen one before (they just check for time based validity). But I get that’s hard to do with a proxy!
Totally fair. Today, we rely on timestamp-based validity checks, but we know that doesn’t fully mitigate replay risk. For the managed version, we plan to track assertion IDs server-side to detect replays. It’s trickier to solve for the OSS version since we don’t manage state, but we’re exploring lightweight approaches there too.
Appreciate your support and agree, SAML isn’t going anywhere anytime soon. Our hope is that SAML Shield makes it easier for teams to secure their stack without having to become SAML experts or wait on upstream patches!
Cool, cool! Thanks for the thoughtful response. Will be interested to see your replay approach when you release it. We implemented it but have a different set of constraints than your service, of course.
If you want to look at another SAML implementation (perhaps to gather additional CVEs or for testing), we've open sourced our SAML bindings for Java: https://github.com/FusionAuth/fusionauth-samlv2
This is neat! We're building something similar at work, but instead of hand-rolling specific checks (like "first signature must be direct child of Response" in samlshield) we're fingerprinting the structure of the SAML response and checking if it matches what we've previously seen from that IdP. We figured that would be more likely to catch any exploitation attempts we didn't anticipate while giving us some flexibility to not have to hardcode specific IdP behaviors. Having specific hard checks seems really valuable too, though, especially for applications that might not have many SAML responses to backtest on. And kudos for sharing a great corpus of test cases!
One thing that would worry me when deploying this in the Proxy mode is that you'll likely end up with two different XML parsers in play: xmldom in samlshield and then whatever the actual application is using. As we saw with CVE-2025-25292, it may be possible to exploit different parser behavior to construct a document that will be interpreted differently between the two applications, potentially bypassing the checks in samlshield.
Interesting approach! (Full disclosure, I work for a Stytch competitor.)
Some initial thoughts:
* nice to ship an OSS version and I appreciated that the OSS limits were clearly called out (only supports node, 1MB limit on XML payload size, you have to update it regularly)
* the docs were helpful and it's great they provide a bad saml response to test with https://samlshield.com/examples/unsigned_saml_response.txt
* critically important to understand that a solution like this isn't the whole enchilada (and they declare that a couple of places): "important to enforce critical checks such as strict Audience and Issuer validation" from https://samlshield.com/docs/get-started-open-source So this isn't a set -and-forget solution.
* if you use the proxy ( https://samlshield.com/docs/get-started-proxy ), it won't be able to check encrypted SAML assertions (how could it, it won't have the key)
* you should definitely read the security coverage page to see what it helps with and what it does not: https://samlshield.com/docs/security-coverage
* replay attacks better protected against by using unique identifiers and invalidating when you've seen one before (they just check for time based validity). But I get that's hard to do with a proxy!
* great to see a transparent pricing page! https://samlshield.com/pricing
I'm all for improving security. SAML unfortunately is going to be around for a long long time and the protocol won't see any updates. This seems like a good step forward in examining SAML requests/responses, even if there are limits to the proxy approach.
Thanks for the thoughtful feedback! (Full disclosure, I work at Stytch and led the launch of SAML Shield.)
> the docs were helpful and it’s great they provide a bad saml response to test with https://samlshield.com/examples/unsigned_saml_response.txt
Glad you noticed that! Including a bad SAML response was a small detail I hoped would make it easier for developers to validate their integration,
> * if you use the proxy ( https://samlshield.com/docs/get-started-proxy ), it won’t be able to check encrypted SAML assertions (how could it, it won’t have the key)
Absolutely and that’s a key limitation of the proxy model. Since the proxy doesn’t have the decryption keys, encrypted assertions need to be handled inside the app. I just updated the security coverage page to call that out explicitly!
> * replay attacks better protected against by using unique identifiers and invalidating when you’ve seen one before (they just check for time based validity). But I get that’s hard to do with a proxy!
Totally fair. Today, we rely on timestamp-based validity checks, but we know that doesn’t fully mitigate replay risk. For the managed version, we plan to track assertion IDs server-side to detect replays. It’s trickier to solve for the OSS version since we don’t manage state, but we’re exploring lightweight approaches there too.
Appreciate your support and agree, SAML isn’t going anywhere anytime soon. Our hope is that SAML Shield makes it easier for teams to secure their stack without having to become SAML experts or wait on upstream patches!
Cool, cool! Thanks for the thoughtful response. Will be interested to see your replay approach when you release it. We implemented it but have a different set of constraints than your service, of course.
If you want to look at another SAML implementation (perhaps to gather additional CVEs or for testing), we've open sourced our SAML bindings for Java: https://github.com/FusionAuth/fusionauth-samlv2
Any opinions you can share re opensaml for Java?
I'm not super close to that part of the code, so I don't have any opinions. I'll ask the team if they do.
This is neat! We're building something similar at work, but instead of hand-rolling specific checks (like "first signature must be direct child of Response" in samlshield) we're fingerprinting the structure of the SAML response and checking if it matches what we've previously seen from that IdP. We figured that would be more likely to catch any exploitation attempts we didn't anticipate while giving us some flexibility to not have to hardcode specific IdP behaviors. Having specific hard checks seems really valuable too, though, especially for applications that might not have many SAML responses to backtest on. And kudos for sharing a great corpus of test cases!
One thing that would worry me when deploying this in the Proxy mode is that you'll likely end up with two different XML parsers in play: xmldom in samlshield and then whatever the actual application is using. As we saw with CVE-2025-25292, it may be possible to exploit different parser behavior to construct a document that will be interpreted differently between the two applications, potentially bypassing the checks in samlshield.
RubySaml contributor here. What I’d like to see is a public repo of known SAML exploit test cases that every lib can validate itself against.
I am working on an SAML Attacker (that basically tests web apps against all known SAML exploits). It includes all the test cases.
I can share you the repository if you want to integrate it in RubySAML (or any other library). Email me [alex]@[securesaml.com] (without the [ ])
thanks for sharing! excited to help make the SAML ecosystem more secure. would love to hear any feedback people have!