Hacker News new | ask | show | jobs
by zwass 2015 days ago
As a service provider, are there viable alternatives to support SSO in an application?
5 comments

OpenID Connect, like others mention, but there's more in life, than only SSO? Organizations also want to automatically deactivate of user accounts?

There's something called SCIM, "System for Cross-domain Identity Management", that does this, and which you can use together with OpenID Connect (OIDC).

SCIM can automatically deactivate a user account, if the person leaves the organization or moves to a different department. And can auto add and remove him/her to/from various user groups.

But with SAML, managers / admins still need to micro manage the user accounts, e.g. place the user in the correct group, if s/he gets a new job role. SAML only syncs user accounts upon login, from what I've understood. (So if the user stays logged in, then, with SAML, his/her account permissions can get out-of-date?)

SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

Azure AD uses this, and Okta, OneLogin, Github and some others too I suppose.

If anyone has tried SCIM it'd be interesting to hear what you think about it? (I've just read about it)

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.

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-...

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.

> 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.)

OpenID Connect seems to be pretty well established: https://openid.net/certification/

It defines an authentication protocol on top of OAuth2, and is a different beast from the older OpenID standards.

CAS looks like the simplest protocol to me https://en.wikipedia.org/wiki/Central_Authentication_Service
If the user interface for TLS client certificates were not so consistently terrible across all browsers on all platforms, I would suggest them.