4 ms·

I fully appreciate how difficult this is to do, but I think it would be immensely useful if WorkOS provided the docs that I (the SAML SP, your customer) provide

I fully appreciate how difficult this is to do, but I think it would be immensely useful if WorkOS provided the docs that I (the SAML SP, your customer) provide to my customers who are setting up SAML (as an IdP) on their end. One of the biggest pain points I've experienced with SAML is that people come to me asking for help, but only understanding their IdP; the only IdP I know how to use is Okta, and I don't have access to their IdP to test with. I'd love it if WorkOS could give me documentation that I can give to my customers about how they can set up Okta/Azure ADFS/whatever with my product. I can edit those docs to account for idiosyncratic stuff my product does (e.g. requiring a particular SAML user attribute or format for user IDs). Aside: the support burden of SAML is a big part of why the sso.tax exists. Nobody on the SP or IdP end knows how to set this stuff up!

grinich 7y ago
Yep we're already looking at doing this with docs. :) One thing to help with the SAML support is WorkOS.js. It's essentially an embeddable configuration flow, so you don't need to build the UI to collect x.509 certs, generate the ACS URL, etc. Similar architecture to "Plaid Link" so users never leave your app. Docs here: https://docs.workos.com/sso/embed-workosjs https://docs.workos.com/sso/embed-workosjs
- ucarion 7y ago
  Yeah this is really cool! To your point about WorkOS.js -- how would a customer know where to find their SAML metadata? Some of this can be done inline in WorkOS.js, of course. But no amount of inline docs in WorkOS.js's UI is going to get around the high-level guidance docs, both for your customers ("where do I even start") and your customers' customers ("how do I fit my IdP peg into your SP round hole").
  - grinich 7y ago
    Ah yeah I'm talking about two different things. The docs for getting SAML config would be on a separate public site. WorkOS.js is for the IT admin to configure their SSO/SAML integration. With both of these things, you can make SAML fully self-serve and include it in your base tier, which drives adoption and retention in bigger companies.

grinich 7y ago

Yep we're already looking at doing this with docs. :) One thing to help with the SAML support is WorkOS.js. It's essentially an embeddable configuration flow, so you don't need to build the UI to collect x.509 certs, generate the ACS URL, etc. Similar architecture to "Plaid Link" so users never leave your app. Docs here: https://docs.workos.com/sso/embed-workosjs https://docs.workos.com/sso/embed-workosjs

ucarion 7y ago
Yeah this is really cool! To your point about WorkOS.js -- how would a customer know where to find their SAML metadata? Some of this can be done inline in WorkOS.js, of course. But no amount of inline docs in WorkOS.js's UI is going to get around the high-level guidance docs, both for your customers ("where do I even start") and your customers' customers ("how do I fit my IdP peg into your SP round hole").
- grinich 7y ago
  Ah yeah I'm talking about two different things. The docs for getting SAML config would be on a separate public site. WorkOS.js is for the IT admin to configure their SSO/SAML integration. With both of these things, you can make SAML fully self-serve and include it in your base tier, which drives adoption and retention in bigger companies.