6 ms·
You need multiple SAML IDP signing keys
- recursive 7y agoI don't understand why all security assertions must always be provided to each service provider. This is probably something fundamental I'm misunderstanding about SAML, but when you authenticate for a particular SP, why does the response automatically include every assertion? It seems too obvious to just configure which claims are issued for each service provider. That wouldn't require any special crypto stuff.
- tptacek 7y agoIt doesn't. The concern is that all of these assertions are captured by the browsers, who are given custody of the signed assertion as part of the SAML POST flow. The attack being contemplated here is that you have a SAML IDP configured for Cat Sharing Application and for Internal Admin Application; a attacker's browser holds onto the Cat Sharing Application assertion and feeds it to the Internal Admin Application, and, because SP SAML libraries are terrible, the Internal Admin Application honors it.
- mc32 7y agoOne hopes the Oktas of the world had this figured out and this is more a problem when you host your own IDP.
- someone13 7y agoThis is part of what makes this class of bug so bad; it's not something you can "fix" at the IDP without doing exactly this. The issue occurs when a Service Provider (SP) is misconfigured, and in many cases the IDP doesn't actually get any sort of feedback that would let them detect the issue.
- mc32 7y agoIs there a way to audit that kind of misconfiguration?
- tptacek 7y agoYes, tediously, with auditors who understand SAML and the (very informal) literature on SAML attacks. Hence, the concern.
- wutwutwutwut 7y agoWouldn't it be enough to enter an invalid audience when configuring the IDP? If the audience is ignored the sign-in flow still allows you to log on and you know the SP is broken.
- lvh 7y agoSure, but two reasons that's not quite optimal and you might not want to do that in practice: 1. This tells you the SP is broken; just using individual keys means that doesn't matter anymore if the SP is broken or not. Individual keys is in your control, fixing the SP much less likely so. And you can just set up a practice of doing it for everything and now it's one less thing to test for. 2. That still requires a bit of testing that's somewhat annoying to set up, which most vendorsec practices don't have time for. It's also only one of dozens of things you need to test for. Ignoring audiences is super common, but a more subtle problem is that you can sign a valid SAML assertion _for the wrong domain_, and now you can sign in as a competitor's staff. As you hint at, having an SP that'll just self-service accept any random metadata.xml at least gives you a fighting chance :)
- wutwutwutwut 7y agoMy question was more related to it being tedious. And now you say it requires a bit of testing which is annoying to set up. Isn't testing this just a matter of changing the audience field to something incorrect and try to sign on? This should take like 2 minutes?
- Androider 7y agoOkta has a single signing key with no ability to set per-provider keys, only Azure AD does the right thing out of the box per the article.
- gabrielsroka 7y agoI believe the article is wrong, eg, see: https://developer.okta.com/docs/guides/updating-saml-cert/generate-new-key-credential/ https://developer.okta.com/docs/guides/updating-saml-cert/ge...
- amaccuish 7y agoHmm. I use simplesamlphp. What would be the easiest thing to change to?
- cosarara 7y agoI implemented simplesamlphp idp two weeks ago, seeing we are a PHP shop it was the obvious choice. Somewhat rethinking that decision now, wondering the same thing.
- amaccuish 7y agoIt's been great for us. Run fine for years, I have docker set to build a new image anytime there's a security issue. Still... I've looked hard at keycloak, but it misses a key feature for us, that you can't store an TOTP secret in LDAP. That's important for us so we just have one code to use, that gets us into SAML, Radius or some of the other stuff we have.
- porjo 7y ago> seeing we are a PHP shop it was the obvious choice A Google search for 'php saml' has php-saml as the top result. I'm curious to know why you chose simplesamlphp over php-saml ?
- johnmaguire2013 7y agophp-saml is a toolkit for making your application a service provider (i.e. able to accept Responses/Assertions from IdPs) so that users can single sign-on to your application. SimpleSAMLphp is a framework/application for creating your own SAMl IdP (i.e. able to send Responses/Assertions to service providers) so that your users (e.g. in an enterprise) can login once and then single sign-on to the rest of your applications.
- fart_ratty 7y agoAccording to the article there is currently nothing that can be done for simplesamlphp. You could open an issue on Github for it. > SimpleSAMLphp’s IDP supports key rollover but no way to specify unique keys for individual service providers. There might be a way to configure it but if so, it’s not mentioned in the documention and I’m not excited to try it myself.
- lr 7y agoTwo 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.
- johnmaguire2013 7y agoEncrypting 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.
- lvh 7y agoSAML 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.
- johnmaguire2013 7y agoDuh - of course. Good point. As long as each SP has its own encryption key, this would be a valid solution assuming SP support.
- mormegil 7y agoSince 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.
- matthewaveryusa 7y agoIf your IDP is providing identity, does it matter who the audience is? presumably the contract is "if this blob is signed with this certificate, then the identity encoded in the blob is the user's identity" because the SP was configured to only trust a certain certificate for identity. What the article is saying is a bit nuanced in that the IDP can theoretically provide a different user identity for each service, but in reality, does that really happen? Seems like if you're doing that you're starting to mix authentication with authorization. The picture in the article that says that the idp provides the answer to "login to cat", "log in to to payroll" is wrong imho. the IDP is providing the answer "username is X", and that's it.
- lvh 7y agoThe article provides examples of the IDP providing using different _IDP identities_ but I couldn't find an example of it suggesting different _user identities_. The problem is the SAML assertion is effectively a bearer token, which is fine if it's specific to a service, and not fine if it can be replayed. If you want to unmix "authentication and authorization" as you put it, you're going to need a way to bind that credential further. You can either do that with some unspecified scheme that nobody implements, or you can do that by just using per-SP keys as the article suggests. What do you propose we do instead?
- matthewaveryusa 7y agoUse a custom scheme because odds are if you're doing things right you'll need a good revocation story which SAML doesn't provide.
- lvh 7y agoThe use case in the article is enterprise login to a bunch of services. It's hard enough to get them to do SSO, you can't seriously suggest you're going to get them to implement bespoke schemes?
- matthewaveryusa 7y ago
- trhway 7y agosounds like an idea of a mix of the better parts of SAML and Kerberos (with the result being kind of fixed Kerberos where SP would store a public key to trust instead of its own private). Of course one may end up with the result being the mix of the worst parts ("Twins" movie comes to mind by association :)
- barryrandall 7y agoSAML is close to what you’d get if you tried to port Kerberos to web technologies. Unfortunately, there are more shitty SAML implementations than Kerberos ones.
- okabat 7y agoAs a SAML service provider, what's the easiest way to tell if my implementation has this problem? I'm guessing I should: 1) Go into my Okta dev account, create a 2nd "okta app" (SP instance) pointing at my hosted application, which should create a new entity ID 2) Start an IDP-initiated login attempt from this 2nd okta app, and verify I get an audience mismatch error
- johnmaguire2013 7y agoThis should work as long as your chosen Entity ID for your second Okta app doesn't match the actual Entity ID of your SP.