Even the ability to just “login with gmail” for non-enterprise accounts would be huge
What enterprise is paying is the convenience, not security itself.
If you as a SaaS provider outsource your SAML integration to a third party provider like Okta or Auth0, the auth provider pricing is immediately on a "call us" tier, with a per-federation pricing in the low four figures for each company connecting via SAML. Let me just state that again, to have company X connect to my SaaS via SAML, I as the SaaS provider have to pay my auth provider $X,000 per year for the privilege, not counting the base enterprise tier pricing for the auth.
OAuth only does AuthZ. I've always found OAuth more complicated because you have to combine it with other technologies to get AuthN
The same could clearly be done for SAML (and I've even implemented SAML and SCIM auth and user management for Okta before in an app, it's not difficult).
The problem is that the only organizations that would make this single issue of SSO support a deal-breaker are bigger companies who can afford to be upsold, so everyone treats this as an up-sell feature. This comes at the expense of the smaller companies, who can't afford to care as much about security. The industry should be making things secure by default as much as possible, and there's a big gap here in what basically every SAAS company is doing.
AuthN: Authentication (who you are) AuthZ: Authorization (what you are allowed to do)
I've never had to clarify what someone is actually trying to accomplish when they want "SAML 2.0"
sources:
* https://help.github.com/en/github/setting-up-and-managing-or...
* https://help.github.com/en/github/authenticating-to-github/a...
[edit: formatting]
SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc.
I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.
Since OIDC is better than SAML, which is probably the scariest security standard on the Internet, I think it's worth being clear to people that OIDC/OAuth is viable.
The SAML authz story, for what it's worth, is pretty shady.
Now that the core Pro features are free, I wonder if Rob will update sso.tax to set Github to :inf:.
Instead of directly bolting SAML into your app, I think a FOSS implementation of an independently running service is the way to go. You run the battle tested open source service (locally / in your cloud), it accepts the SAML assertions and mints something sane like JWTs which can easily be consumed by the service providers, isolating the entire thing from your core app and allowing it be used with any stack. E.g. essentially an open source locally deployed Okta. Doesn't even need to do any user management, just focus on rock solid interoperability and forward all decision making to the actual app server.
There's a lot of functional overlap between SAML and OIDC/OAuth, but SAML is a very different (and idiosyncratic) protocol; the "what" is the same, but the "how" is very different.
OAuth is way more complex, I've used it countless times and still get confused by it. It has more complex patterns like having a separate resource server and authentication server, it's used for more purposes, e.g. sometimes for API access and sometimes for login and sometimes a confusing mix of both, and there are big differences between v1 and v2 and some services are still using v1.
I'm however speaking from the point of view of the service provider (the SaaS app) and about SAML in particular. I feel that the addition of SAML into a given service is a net-negative from that service's security point of view. It's a large additional complex attack surface, many open source SAML libraries that I've reviewed have a history (and in some cases open issues right now) of "pants on head" type of security errors. A popular library in use right now, has a known race condition where it gets confused if there are concurrent SAML requests happening.
And that's just the libraries. Then you have to use them correctly. The libraries do the absolute minimum checking since they don't have the context, you have to add a laundry list of your own checks to them. Just recently there was a HN article about taking SAML assertions posted to provider A and re-using them on provider B, where clearly the most basic of checks aren't in place at all. There's all kinds of confused-deputy type of problems I believe most service providers don't think about at all. And that was an easily offline checked attribute, I believe if you'd start to check how many services correctly implement even the basic "inResponseTo" check on SP-initiated flows (which requires a distributed cache on the service provider side), you'd find they don't.
Meanwhile: we're discussing Github, not a random cat-sharing startup. Github has one of the larger security teams in the industry. The parties implicated in Github SAML are Github, Okta, and Github customers, who do not actually have to implement SAML. Github SAML is not in fact a net-negative for security.
That's not true. We are a tiny company (~10 ppl), but SAML, OIDC (or GSSAPI or Radius, if really necessary) support are a deal-breaker for anything we use.
We used to have separate accounts for everything we had. It became a drag, we had to solve it. Nowadays, either it can be integrated with SSO, or we will do without.
> so everyone treats this as an up-sell feature.
And that's the mistake.
You want Keycloak - https://www.keycloak.org/ - then.
I once tried to implement it, and found that the specification was spread across ~500 pages of dense PDFs. I find it to be complex.
Source: Watching an alcoholic CTO get fired by the board and taking the startup's hosted Mongo database hostage
I have a theory that one reason we don't see many your-SAML-implementation-is-completely-broken reports is precisely because it's a gated enterprise feature, so few independent security researchers have the access or ability to poke and prod at them outside of private penetration tests.
The worst bugs here are indeed mostly private, but that's because they're feature bugs inside of people's random products; they're like every other bug in that regard. But people do find and report bugs in the SP libraries.
I agree that SAML is risky to implement; since we agree that Github SAML is an unalloyed good thing, we'd be searching for reasons to disagree at this point.
If you want self hosted IAM solutions. The most common one is Microsoft active directory. It provides both SAML and OpenID Connect integrations out of the box as of ADFS 2016.
Still, SAML requires to onboard applications individually, create keys, and stuff. It's not plug and play, it really needs humans on both sides to add a new service.
You take some open source pieces you can (saml, xml, oidc, ssl, jwt) but permissions, groups, user attributes, keys are always per company then the whole thing together has to be supported into end-user applications running on language and frameworks of the day with their own restrictions, so custom.
The messages are under specified and overcomplicated, doing incredibly obscure stuff (XML signing and canonization for one) that nobody can understand and implement. That's mainly why it's so hard to use and there is so little support from libraries.
As security researcher, we could nitpick all days on security being hard, no matter the solution. It is factually true but it doesn't help developers, fact is, developers would be better off ignoring SAML and going with OIDC instead.
It does work for the basic use cases, so I would still consider that an better option than rolling your own for the average service provider.
2. I think the product complexity issues are, like, 95% the same whether you use OIDC or SAML.
3. I think no matter how much simplification you got from using OIDC instead of SAML, none of it is going to offset the actual reason why SSO integration is a paid feature.
4. I agree that SAML is much worse than OIDC from a protocol implementor's perspective even if I'm not so sure that it's much better from a developer's perspective, so wouldn't want to find new reasons to disagree.
Even in cases where the IdP supports both SAML & OIDC, I see almost no one choosing to use OIDC (a case of the devil you know?). The only real users of OIDC in an enterprise setting I see as a service provider, is G Suite businesses.
I'm pretty sure OIDC can be supported everywhere now. Okta, Oauth, PingIdentity, ForgeRock, Microsoft all support both. The last offender was Microsoft but it's included with active directory since 2016 both on premise or through Azure.
I'm working on auth for a big bank and it's definitely there, although not necessarily advertised and not everybody understand what is supported or preferred.
If a company were to only support OIDC nowadays, and maintain that OIDC is the preferred protocol when customers ask "can you do SAML?", I am willing to bet that most customers would integrate just fine either way.
One can find an open source library to handle part of the SAML or XML in Java, but it doesn't take the right settings or import user attributes as needed or handle URL redirections properly. So the company has to write a ton of authentication code to make it work. It may start from an open-source library but the result is either separate code on top or an outright fork.
The company will end up writing a ton of authentication and authorization code --- it'll do that no matter what, because the application will have its own security logic, like all applications do.
(OIDC doesn't use XML. But the story is the same, with different endpoints.)
Ironically, the first point makes me realize that half the work to bring in a product in an entreprise is to deploy and set it up -properly with authentication- while the other half is to get the budget and approvals to buy it. Thus it's rather relevant to the thread in an unfortunate way.
The opposite certainly exists though, for example simplesamlphp which gets commingled into a php app codebase as you described.