Surprisingly the page doesn't explain the meaning of SAML. It's Security Assertion Markup Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...
"Suffering A Massive Lot" - jk
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.
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.
> 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.
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.
The document is open source: https://github.com/ssoready/docs/pull/55
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.
Storing user passwords yourself is a liability, indirect or direct: https://www.reuters.com/technology/eu-privacy-regulator-fine...
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.
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.