3 ms·

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

by 80x25 4y ago

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 4y ago
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.
- aisrael 4y ago
  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 https://www.propelauth.com
- grinich 4y ago
  WorkOS provides this via the "Admin Portal." https://workos.com/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/ https://demo.workos.com/ (I work at WorkOS. :))
caloique 4y ago
Not necessarily, there are actually 3 options: Buy vs Build vs Use OSS :) > https://github.com/boxyhq/jackson https://github.com/boxyhq/jackson
- 80x25 4y ago
  "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".

by 80x25 4y ago

buzer 4y ago

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.

aisrael 4y ago
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 https://www.propelauth.com
grinich 4y ago
WorkOS provides this via the "Admin Portal." https://workos.com/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/ https://demo.workos.com/ (I work at WorkOS. :))

caloique 4y ago

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

80x25 4y ago
"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".