> 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!