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.
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.
You're right that per-SP pairs are still the right answer and for the reason you point out: much wider support.
You can't drop that and walk away without naming them.
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.
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 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?
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.
Above and beyond that, support is tremendously variable. Ability to do JIT provisioning/re-provisioning with user roles etc mapped to attribute assertions is something like nirvana and about as commonly realized.
"SSO once you have pre-provisioned the user out-of-band via our application-specific API" is more common (bonus marks for SCIM). Also "SSO assuming you can provide access to an LDAP server where we can look the user up".
(Completely agreed that the vast majority of SSO integrations only let the IdP assert identities, not group memberships.)
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
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.
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 :)
So, sure: you can test this one specific bug by replaying an assertion for a different SP. Or you can make your IdP use new key pairs every time and then you're definitionally immune to the entire bug class forever with every SP. Even if replaying the SP takes 2 minutes, getting the tester to a place where they can exploit it takes way longer for most companies, so it's much more effective to just eliminate entire classes of bugs via policy.
TL;DR: you're right (modulo the amount of time) for this particular bug, but why bother? And if you're going to bother testing, why test for this one specific bug that's cheaper to avoid a different way? (I can think of a reason to test; but then the tedium comes in :))
The challenging part is doing it for vendorsec, when you are vetting _other apps_. The timelines that stakeholders (other people in the company who want to use the app) are willing to accept are like, a week, and even if you somehow had a SAML testing praxis at the ready that enumerates all of the problems SAML has historically had, there's a lot more to test than just the SAML bits.
So: in summary: I don't think that number is anywhere near zero, though sure, it's not huge. The hard part is failures being silent and being in parties you don't control.
> Correction: SimpleSAMLphp easily allows for per-SP signing certs/keys. See https://simplesamlphp.org/docs/stable/simplesamlphp-referenc... (signature.certificate and signature.privatekey)
> 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.
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 ?
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.