zlacker

[return to "Launch HN: SSOReady (YC W24) – Making SAML SSO painless and open source"]
1. bilalq+wp[view] [source] 2024-07-30 18:21:11
>>ucario+(OP)
These days, I feel like this biggest obstacle with SAML is integrating with SaaS products. I've been in many situations where it requires back and forth emails to a support team. I've been handed a literal 204 page PDF on integrating with one vendor's SSO setup (the entire document was literally just for their SSO integration, nothing else). Attribute mappings are still a mess. It's wild how poor the experience still is.
◧◩
2. ucario+qu[view] [source] 2024-07-30 18:43:55
>>bilalq+wp
I've written one of these 204-page PDFs before (I think it was more like 20 pages though). The IDPs don't exactly make it easy on their customers to set this stuff up, and the burden ends up on the SP (i.e. you) to document to folks how to use their own IDP.

Incidentally we just shipped something for this. Rather than having to make a 204-page PDF, you can go into SSOReady, generate a setup URL, and give it to customers. Customers can visit that URL and they get a self-serve UI for configuring their SAML connection to your product.

https://ssoready.com/docs/idp-configuration/enabling-self-se...

◧◩◪
3. mwcamp+hJ[view] [source] 2024-07-30 20:13:52
>>ucario+qu
Wow. My company previously did an SSO implementation for our SaaS where we ran Shibboleth SP behind Apache just for SSO, with a little Python web app using mod_wsgi to call back to the main web app after SSO was completed. But for the customers that we've onboarded to SSO so far, we had to contract with a SAML expert to work with the customer to set it up. This self-service setup might be enough to make it worth our while to migrate to SSOReady.
◧◩◪◨
4. crngef+Rx1[view] [source] 2024-07-31 06:19:39
>>mwcamp+hJ
Sounds horrible, why would you use Shibboleth in $currentyear if you could just use OIDC?
[go to top]