1

I have an app where I may choose to configure SAML2 login in the app with:

  • Public cert of IdP
  • IdP SAML2 login URL
  • IdP entity ID

I may also choose to, instead, provide an HTTPS metadata URL from which all of the above information is fetched. The latter implies less configuration but I'm wondering about the security aspects? I have verified that the framework validates the SSL connection for acquiring the metadata, but are there other aspects that make one of these methods preferable to the other?

Improve this question

1 Answer 1

Reset to default
1

There are security trade-offs in both approaches. With the manually-configured public key you are less vulnerable to DNS and BGP hijack (example: https://www.cyberscoop.com/ether-dns-bgp-amazon-route-53-heist/) but you are more vulnerable to social engineering: who is authorized to send you new public key when the old one expires, and how do you know it's really the right person? Related: why use a CA-signed key pair to encrypt SAML2 assertions?

Note that the (newer than SAML) OIDC protocol also supports metadata URL (JWKS URI), e.g. https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-sets and in practice the providers encourage their use over manual key configuration.

Improve this answer
5
  • But if the https connection used to fetch the metadata is verified, then on top of DNS / BGP hijacking, a rogue CA would be needed, otherwise the connection would be turned down? Also, I manually acquire the IdP certificate from its website (trusted https connection). So in fact, with a manual config, I ONCE rarely (when the cert is updated) trust a https connection to be legit which I do at EVERY APPLICATION startup with the metadata URL. Seems then that manual config would be more safe, albeit both might be safe enough :)
    – fast-reflexes
    Apr 12, 2022 at 7:48
  • Finally, is something different with OIDC or why would a metadata URL be more trusted there than in SAML2?
    – fast-reflexes
    Apr 12, 2022 at 7:48
  • Regarding forged cert, see the linked article. Services like LetsEncrypt depend on control of the resolved server, which the attacker would have due to their other forgery.
    – explunit
    Apr 15, 2022 at 16:54
  • 1
    OIDC isn't necessarily different. I'm just pointing out that even with several more years of security research, the newer protocol encourages metadata URL.
    – explunit
    Apr 15, 2022 at 16:55
  • In the article it even says that the certs were probably not forged and so the users would have had to accept an announcement about unsecure connection. But just because someone has spoofed the DNS service that I use when fetching the IP of the metadata uri, it's not necessarily the case that they also have managed to spoof the DNS servers used by Let's Encrypt and if so, they couldn't fake a cert, or you assume that if someone manages to inject fake DNS data it will propagate so that Let's encrypt will eventually resolve the URI to the fake server as well whereupon a fake cert can be fetched?
    – fast-reflexes
    Apr 24, 2022 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .