We wrote our own IdP back in the day. It was a cool project, Single Sign On, Single Sign OUT, User provisioning, just all sorts of stuff.
And it worked! It's amazing when it works, it's just like magic. You giggle when it works.
We did all sorts of integrations. To random Service Providers, integrating with other IdPs, etc. Some were really cool. Great functionality.
But I simply float this one caveat.
It was never "painless". Ever. It was always pulling teeth.
The dark truth is you can have the best IdP in the world, but everyone on the other side of the conversation is a black box. You get a lot of payloads simply shipped into the void, never to be seen again, consumed for some unknown reason.
Add to that the very often the people you're integrating with have no concept of SAML, its workflows, its payloads, etc., much less the capabilities of their own stack in regards to SAML. So you get to train them (and learn about their system) at the same time.
We never had real problems with signing and formatting and such that folks worry about. It was mostly just diagnosing black boxes more than anything, the endless black hole of cert management, etc.
So, good luck! I hope it works for you! It's a neat space to play.
> And it worked! It's amazing when it works, it's just like magic. You giggle when it works.
And then this
> It was never "painless". Ever. It was always pulling teeth.
Even with a caveat in between, is misleading. I get you’re probably trying to generate revenue, and more power to you. I’d re-work that phrasing next time.
This is true of a great many protocols, unfortunately. I've seen this with IPSec, HL7v2, … CSV.
IPSec was perhaps the most … scarring. Always sort of feeling your stomach turn to acid as you wonder to yourself "will we be able to integrate with the other end?" when you're trying to work with "network engineers" who cannot establish a TCP connection to test if the VPN tunnel is alive. And yeah, it's learn their system as fast as humanly possible to then determine if their setup is correct, and to hunt where the inevitable integration problems lie. (…in the firewall. It was always a firewall, somewhere.) Why other systems feel the need to take the standard terms and reinvent new words for them is beyond me to this day. "Enterprise" junk is particularly guilty of it. Most of the learning is just building a mental Rosetta stone of what does the other end's "appliance" call this term or that term.
One of my favourites was the time I was trying to figure out a SAML integration with a client, and before the person on the client's "SSO team" could figure it out, I installed a demo of their SSO solution, integrated with my own dev AD, and found the checkbox.
Yay enterprise! The Q in enterprise is for quality.
SPF, DMARC, DKIM is setup correctly. Domain name A/AAA/TXT/MX records all setup and propagated throughout the world. Mail server tested with external tools like mail-tester.com
…
But there is a whole new world of “other mail servers” now. Some mail servers are okay. Delivery works fine. Some mail servers have odd policies and implement strict block lists and maintain their own rep of each domain/sender.