Hacker News Reader

Comment by lr | Hacker News Reader

Two ways I deal with this:

1) Insist on encryption of the SAMLResponse (that way, the SP has to do it correctly, or they'll have no idea who is accessing the app) 2) If they won't do encryption, I test exactly what they are talking about in this article

To test, I have my own IdP set up, and I either do IdP-initiated sign-on or spoof the IdP URL using /etc/hosts on my localhost and try to log into the app with a signed SAMLResponse using a key the SP doesn't know about. If it works, I immediately tell our CISO. I even scared one vendor so badly just explaining that I was going to do this that we never heard from them again.

View on HN

It sounds like it would be really useful to have a public IdP that does this, kind of like badssl.com is a demo site for showing how various misconfigurations present in browsers.

Encrypting the Response only ensures that the SP knows how to decrypt it - not that they are verifying other fields, like the Audience field.

If you use a separate encryption key for each SP, then great - but you could just as easily use a separate signing key, as the article suggests, and far more SPs support this.

Of course, it is still possible the SP does not validate the signature at all, or does so erroneously.

SAML typically uses RSA-OAEP or RSA-PKCSv15 for KEM. You usually get the cert from that from the SP (since otherwise you hold the private key), so I'm not sure how that goes sideways. The SP might still use the same encryption keys for each peer, but that should be fine.

You're right that per-SP pairs are still the right answer and for the reason you point out: much wider support.

Duh - of course. Good point. As long as each SP has its own encryption key, this would be a valid solution assuming SP support.

Since the encryption is typically asymmetric, you do have per-SP encryption keys, since you encrypt using the key specified in the metadata provided by the SP. On the other hand, the SP verifies the signature using the public key specified in the metadata of the IdP. So, to have per-SP signing key, you need per-SP metadata, which is an additional complication.

>I even scared one vendor so badly just explaining that I was going to do this that we never heard from them again.

You can't drop that and walk away without naming them.

Reading this article tonight then BC I wanted to know how to size up such integrations at very early stage. Thanks for the pro-tip!

Reply on news.ycombinator.com