You need multiple SAML IDP signing keys (opens in new tab)

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.

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

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

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?

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.

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)

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.

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.

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.

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.

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.