You need multiple SAML IDP signing keys

https://www.stackallocated.com/blog/2020/saml-idp-no-shared-keys/

by hansnielsen • 6 years ago

64 45 6 years ago

recursive• 6 years ago

I 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.

tptacek2• 6 years ago

It 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.

mc322• 6 years ago

One hopes the Oktas of the world had this figured out and this is more a problem when you host your own IDP.

amaccuish2• 6 years ago

Hmm. I use simplesamlphp. What would be the easiest thing to change to?

cosarara• 6 years ago

I 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.

amaccuish2• 6 years ago

It'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• 6 years 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 ?

fart_ratty• 6 years ago

According 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.

radlad7• 6 years ago

I replied on Twitter, but I'll include it here as well:

Correction: SimpleSAMLphp easily allows for per-SP signing certs/keys. See https://simplesamlphp.org/docs/stable/simplesamlphp-referenc... (signature.certificate and signature.privatekey)

lr• 6 years ago

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.

radlad7• 6 years ago

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.

lvh8• 6 years ago

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.

mormegil• 6 years ago

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.

philsnow• 6 years ago

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.

616c• 6 years ago

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!

ThePowerOfFuet• 6 years ago

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.

matthewaveryusa3• 6 years ago

If 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.

lvh8• 6 years ago

The 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?

matthewaveryusa3• 6 years ago

Use a custom scheme because odds are if you're doing things right you'll need a good revocation story which SAML doesn't provide.

NovemberWhiskey2• 6 years ago

If your SP supports it, you use SAML attribute assertions to model group/role memberships and only grant access to users in the appropriate groups.

Or you have your IDP (say ADFS) only permit issuance for authorization requests which are appropriate, again by reference to (say) AD group memberships.

If your SP doesn't even validate the audience for the assertions, then you're definitely going to be in a bad place - but the question there is "how do I limit the damage this braindead SAML implementation can do to my enterprise and how do I make sure I never buy software broken like this again?" rather than a screed suggesting authentication and authorization are the same thing.

radlad7• 6 years ago

It is common for an IdP to apply specific policies and controls dependent on which service provider the user is authenticating to. The IdP is specifically saying "user X has access to application Y." That is why the Audience is a (required) component of a SAML Response.

rb12345• 6 years ago

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.

It's not a scenario you're likely to see in the case of corporate SAML use, where people generally don't care about anonymity to SPs, but it happens fairly routinely in Shibboleth environments with multilateral federation. In that scenario, you often want proof of the user's membership of the organization (or their role within it) and the ability to track a specific user of the service, without being able to expose who the user is. In that case, your user identifier attribute ends up being an opaque ID, which is either random or a hash of username+SP-entity-ID+salt. Using that approach, there's no way to tell if user X at journal site A is the same as user Y at journal site B without the assistance of the IdP owner.

trhway• 6 years ago

sounds 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• 6 years ago

SAML 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• 6 years ago

As 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

radlad7• 6 years ago

This should work as long as your chosen Entity ID for your second Okta app doesn't match the actual Entity ID of your SP.

You need multiple SAML IDP signing keys

Related Stories