[80x25]

This post seems to suggest that a SaaS startup would consider creating their own SAML implementation. If a SaaS startup is considering creating a homebrew SAML implementation, they are doing it wrong.

When it comes to SSO, "buy" instead of "build", and focus on the core value proposition of the service with that saved time and resources.

[buzer]

Out of curiosity, which SSO service providers allow end-customer to self-configure the SAML integration? Essentially every service that I have seen the SAML integration is only configurable by the service provider and often there isn't even API that could be used to let SP expose the functionality.

[grinich]

WorkOS provides this via the "Admin Portal." https://workos.com/admin-portal

It's essentially a hosted UI that allows end-customers to fully configure SSO/SCIM/etc.

Demo: https://demo.workos.com/

(I work at WorkOS. :))

[aisrael]

This is actually something we’re working on at PropelAuth[0]. Our general philosophy is that most SP’s don’t want to deal SAML and would prefer to just have their users manage their own org membership - whether that’s via SAML, invitations, etc.

We haven’t built an API for it though, instead opting for a UI that walks the end-user through the steps of integrating with their IDP. That’s partially because every IDP is so different that we felt you really need a UI to show exactly what to do.

[0] https://www.propelauth.com

[caloique]

Not necessarily, there are actually 3 options: Buy vs Build vs Use OSS :) > https://github.com/boxyhq/jackson

[80x25]

"Use OSS" is very close to if not the same as "Build".

To adopt an OSS approach for SSO, the startup still needs to dedicate resources to researching the OSS options, deploying the OSS, integrating it, and most importantly, operating it.

Once the startup gets into the weeds of integrating SSO functionality with customer's IdPs, in the limit, the cost of the effort will start to approach "Build".