4 ms·

Depending on who your customers are, you might get away with only supporting OIDC. But not supporting SAML is going to be a problem as you move into the big ent

Depending on who your customers are, you might get away with only supporting OIDC. But not supporting SAML is going to be a problem as you move into the big enterprises. Many big companies run on SAML, and expect to auth with vendors over SAML. That's why russell_h's comment is probably futile; it's the enterprises with the big SaaS budgets that keep SAML relevant, and they don't care if HN doesn't like it. Maybe in about a decade SAML will be less important to enterprises? SAML 2.0 is only about 15 years old.

KajMagnus 6y ago
What about SCIM, "System for Cross-domain Identity Management", instead of SAML, if creating software for enterprises? SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning#what-is-system-for-cross-domain-identity-management-scim https://docs.microsoft.com/en-us/azure/active-directory/app-...
- ucarion 6y ago
  SCIM is a pleasure to implement compared to SAML, no doubt. You might be able to get away with only supporting SCIM, the main thing you'd be missing is "just-in-time" user provisioning. But given that you'll probably need SCIM at some point anyway, probably a good idea to start with SCIM, and then add SAML only when you need to! It'll also inform what subset of SAML you actually need to implement.
  - KajMagnus 6y ago
    > good idea to start with SCIM, and then add SAML only when you need to Sounds like a good approach yes. (It seems you've added SCIM to some software? About how long did it take? Was there any "gotchas") > the main thing you'd be missing is "just-in-time" user provisioning Hmm could that depend on the organization using the software I'm developing? — Possibly they'll synchronize user accounts and groups, upon installation of the software, and whenever anything changes — and then all user accounts will be ready already, when someone wants to log in. But if they syncronize only, say, once a day, then, with SAML, one could still log in, and the account would get created and added to the correct groups, also if the sync that would create one's account, hadn't happened yet? (OIDC could help a bit, but it doesn't understand user groups and permissions, only SAML and SCIM does, right.)

KajMagnus 6y ago

What about SCIM, "System for Cross-domain Identity Management", instead of SAML, if creating software for enterprises? SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/user-provisioning#what-is-system-for-cross-domain-identity-management-scim https://docs.microsoft.com/en-us/azure/active-directory/app-...

ucarion 6y ago
SCIM is a pleasure to implement compared to SAML, no doubt. You might be able to get away with only supporting SCIM, the main thing you'd be missing is "just-in-time" user provisioning. But given that you'll probably need SCIM at some point anyway, probably a good idea to start with SCIM, and then add SAML only when you need to! It'll also inform what subset of SAML you actually need to implement.
- KajMagnus 6y ago
  > good idea to start with SCIM, and then add SAML only when you need to Sounds like a good approach yes. (It seems you've added SCIM to some software? About how long did it take? Was there any "gotchas") > the main thing you'd be missing is "just-in-time" user provisioning Hmm could that depend on the organization using the software I'm developing? — Possibly they'll synchronize user accounts and groups, upon installation of the software, and whenever anything changes — and then all user accounts will be ready already, when someone wants to log in. But if they syncronize only, say, once a day, then, with SAML, one could still log in, and the account would get created and added to the correct groups, also if the sync that would create one's account, hadn't happened yet? (OIDC could help a bit, but it doesn't understand user groups and permissions, only SAML and SCIM does, right.)