Comment by cactus2093 | Hacker News Reader

Comment by cactus2093 | Hacker News Reader

Parent Full thread

This doesn't make sense. Login of any kind can be a tricky problem, you need to handle passwords, rate limits, email verification, password resets, etc. In most popular web frameworks there are libraries you can drop-in that handle all of this for you (like Devise in rails). There are drop-in libraries like OmniAuth (again for ruby/rails) to make handling multiple types of Oauth login simple.

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.

> 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

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.

Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those.

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.

It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).

SSO is a great benefit to the customers, with real tangible security and management benefits.

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.

I'm a security researcher with a minor focus in SSO libraries, working on OIDC and SAML right now. I've discovered and reported some of the kinds of issues you're referring to. Both OIDC and SAML are fraught in implementation, but so are all login features.

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.

100% agreed, GitHub SAML is unequivocally good. I'm in the "cat sharing startup", so my view and comments are colored by that perspective. Our options are to pay $$$ for a competent auth provider, or take on a much larger and complex security responsibility than it would seem at first, that might end up compromising our entire service.

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 riskiest components in SSO deployments are SP-side libraries, and those are all open source. If you want to use Okta to drive those libraries, the trial account you need is free.

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.

I'm surprised you'd say SP-side libraries are open source. In my experience, it's always been mostly custom and close source in every company I've seen and done.

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.

What's the closed-source SAML library you're thinking of? Every SAML integration I've seen has been done with an open-source library.

I mean the company is writing it's own code for a significant part. Let's say one has to integrate SAML/OIDC into a Java app of some sort.

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.

One will find a library to do the SAML. That library will almost certainly do the XML (most likely with xmlsec1). The library will have a call for the ACS endpoint, for the SSO login endpoint, and maybe for the SLO endpoint; it won't implement the endpoints itself, but it'll implement all the logic of the endpoint.

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

What's are the other contenders for top 3?

MDM or endpoint tracking, and then it gets diverse.

Reply on news.ycombinator.com