Oh, I thought it stood for:

"Suffering A Massive Lot" - jk

Let's just say my interaction with managing websites that used SAML was less than pleasant.

> Let's just say my interaction with managing websites that used SAML was less than pleasant.

My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks.

It combines all the wonderful antipatterns you can name: a protocol where near everything is optional and two standards-compliant implementations can refuse to cooperate in any number of ways, hair raising security decisions (XML-DSIG?! configurable crypto? ughh), and half-baked features (back-channel SLO, anyone?)

It's a Lovecraftian horror that actually makes me appreciate JWTs.

Do you renew the certificates used to distribute the public keys in SAML metadata, and if so why do you do it? I have had a hard time convincing people it is useless to renew those certs and have yet to find an implementation that care about those certificates.

Renewing the certificates seems technically pointless, but some organizations/federations require it.

Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.

Make senses, most bigger federations do not bother with this luckily for us it is just specific idps.

> synchronize the metadata updates

Sadly I know many implementations that do not handle key changes in the metadata in a smooth way. The two SPs I have from Adobe both require manual updating of one key per idp, making a switch pain to synchronize.

All my x509s for SAML signing are self-signed, and all my self-signed certs live for 9999 days and I plan to let someone else figure out the fallout from that as I'm going to be /retired/. No one has ever really complained. Some IdPs I've integrated with use certificates that are signed by public CAs and it's always a hassle because the ergonomics around it are terrible.

IMO, I think rotation is wildly useless too. It might make sense in a world where my signing certificate was decoupled from the metadata someone else has to very likely load by hand.

I was also the SAML person at one point in my career and I 100% agree. I used to laugh at all the HN criticisms of JWT because of how much of a nightmare SAML is.

Cthulhu does not appreciate being associated with this.

Yes, JWTs are so simple compared to what came before that it's hard to argue with them. Just make sure your verification doesn't allow none or old ciphers and you're basically fine.

Thanks, I had wondered about that, though I was certain that the S didn't mean simple.

Everybody who worked with it knows that S stands for Shitty.

Suggest Alternative Modern Login: OIDC/Oauth2 ?

The "Continue with" buttons that include Microsoft, Google, and Apple, tend to pick up most SMBs without SAML SSO headaches on either side.

Like so:

https://www.xsplit.com/user/auth

https://id.atlassian.com/login

Use an email domain restriction, and you have by and large SSO; the user can only log into your SaaS if the user is an active account at that company.

As someone who worked at a very large SaaS company this is a good recommendation if the vast majority of your customers come from large enterprises with competent IT departments.

The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs.

Use an open source identity provider or pay someone to do it for you.

I'd argue you're half right.

Yes, it is a good recommendation if the customers have an IT Department.

But I'd argue you're missing the other half.

It's an even better recommendation if the customer is using M365, Google Workspaces, or Apple Business Manager, without an IT Department, since they don't need an IT Department at all to get effectively the same benefit as SSO.

After your initial setup to accept OIDC as the SaaS or PaaS, neither you nor the customer have to do an "integration" to support additional customers of Microsoft, Google, or any other OIDC provider you add. You could let your customer validate an email domain to ensure their sign-ins are theirs, but other than that, once you support OIDC with their provider, nobody has to do anything.

Something on the order of 80% of SMB in the U.S. are on O365/M365 by some measures, and judging from startups here, every tech startup thinks everyone's on Google Workspaces like they are, so that's the other 80%. :-) Toss in socials if you are B2C instead of B2B, and of course Apple IDs if you are targeting users by "wallet share".

You get the key benefit of SSO while your clients do not need to integrate one by one. And...

> Use an open source identity provider or pay someone to do it for you.

Or, don't do that effort at all, use what's baked in and just take the win.

Oh, good callout!

The document is open source: https://github.com/ssoready/docs/pull/55