How Slack Lands Big Deals(workos.com)
workos.com
How Slack Lands Big Deals
https://workos.com/blog/how-being-enterprise-ready-helps-slack-land-big-deals
1 comments
How long does it take add a new IdP?
And what would be the process for that?
I work at WorkOS and we've done this with our product, so I can tell you with a lot of precision how much this costs. ;)
The time it takes depends on the Identity Provider:
• For a OAuth provider (like G Suite or GitHub) you'll need need to set up unique redirect URIs and token exchange code on your backend for each system.
• For a SAML provider, you need to collect the IdP URI and X509 certificate to do the SAML assertion. You also need to ensure the fields coming back in the SAML response (XML) map to your database. These fields are non-standard so you need a configuration UI for mapping. Many services have actually implemented SAML incorrectly so you need to deal with that too. e.g. VMware ONE has some non-standard stuff they do with certificates.
• For other non-SAML providers, you'll need to custom build for the protocol. "AD FS" is Microsoft's flavor of federated auth and it's a bit different. (Has a relying party trust cert.) Another is "OpenID" which is structurally similar to SAML but based on OAuth2/json instead of XML.
• Then you need to build the set-up UI for this (unless your support team is going to do it manually every time). With that you usually need to write docs with screenshots of every provider. You should also keep a database of test accounts for every identity system and integrate this with your CI tests so you can detect regressions in the identity systems.
In economic terms, this has been about a year of ongoing work with a decent sized team. (And we're still not finished yet.) SSO a fractal problem because there's such a long-tail of identity systems and configuration options.
The time it takes depends on the Identity Provider:
• For a OAuth provider (like G Suite or GitHub) you'll need need to set up unique redirect URIs and token exchange code on your backend for each system.
• For a SAML provider, you need to collect the IdP URI and X509 certificate to do the SAML assertion. You also need to ensure the fields coming back in the SAML response (XML) map to your database. These fields are non-standard so you need a configuration UI for mapping. Many services have actually implemented SAML incorrectly so you need to deal with that too. e.g. VMware ONE has some non-standard stuff they do with certificates.
• For other non-SAML providers, you'll need to custom build for the protocol. "AD FS" is Microsoft's flavor of federated auth and it's a bit different. (Has a relying party trust cert.) Another is "OpenID" which is structurally similar to SAML but based on OAuth2/json instead of XML.
• Then you need to build the set-up UI for this (unless your support team is going to do it manually every time). With that you usually need to write docs with screenshots of every provider. You should also keep a database of test accounts for every identity system and integrate this with your CI tests so you can detect regressions in the identity systems.
In economic terms, this has been about a year of ongoing work with a decent sized team. (And we're still not finished yet.) SSO a fractal problem because there's such a long-tail of identity systems and configuration options.