[ArchOversight]

I feel like a lot of the issues are also due to Azure making it vastly more difficult than necessary to configure OIDC/SAML and get the right information over to the SP.

[scott_w]

I don’t doubt that, however the vendor doesn’t get a choice over the IDP and Azure isn’t even the worst! Last week we had to create a custom Metadata XML file for a customer because their IDP doesn’t accept self-signed certificates. For a certificate we send them. That we can validate on a call with them. And it’s completely undocumented in their IDP’s docs.

[ArchOversight]

That shouldn't mean that you lock the feature out for customers that do have someone that can troubleshoot it/get it up and running without help.

Lock support for SSO up behind a paywall, not the actual feature.

[scott_w]

What do you do when the customer locks themselves out? We have a good reputation for support so suddenly throwing up “sorry, no” will tank that.

This still doesn’t override positioning. Companies can make more money by charging more money for it, so they do.

[slooonz]

"Your issue is coming from a misconfigured SSO. We disabled SSO on your account, you can login with the standard password reset flow. You can reenable SSO once you have fixed the issue."

[scott_w]

And when you have to unlock it for the fifth time? This is looking like a shit product and shit customer support.

[phantompeace]

The customer misconfigured their SSO 5 separate times? Sounds like you don’t want that kind of customer in the first place to be honest.

[cratermoon]

Azure AD or whatever they are calling is now isn't even fully SAML 2.0 compliant, so of course it generates support calls. Then the answer from MS support is "use this workaround" and now your implementation is locked into Microsoft's implementation.

Sound familiar?